Comments 60
Привет! А почему вдруг грейдов перестало быть достаточно для отделения квалификации одного тостера от другого?)
В том то и дело, что мы относимся к словам QA и QC не как к "ярлыкам". Для нас это процессы, которыми мы занимаемся. И занимаемся мы ими не чтобы набить цену, а чтобы приносить пользу)
отделить квалификацию одного тостера
от микроволновки? ;)
(простите, не удержался)
Спасибо большое за статью! Эта тема реально абсолютно нигде не раскрыта в нормальном виде.
Да это как DevOps инженер. Подход стал должностью
Да, эта аббревиатура уже настолько навязала в зубах, что уже начали придумывать всякие эвфемизмы для неё - например quality assistance - "содействие в обеспечении качества"))
Поэтому, вопрос действительно важный, но... Не докрутили вы, ребят. Даже, совсем наоборот - пошли в какие-то дебри...
Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Поэтому первый вопрос, который мы должны решить - не как внедрить ci/cd или в линтер чего нового запихнуть - а как сделать так, чтобы Леша стал Васей. Если есть деньги и нет времени - Лёшу можно уволить и нанять ещё одного Васю - и, да, это будет самым что ни на есть обеспечением качества. Или, Лёшу можно научить - на рабочем месте, что всегда и ставил во главу угла "папа" качества в его современном понимании У.Э.Деминг
Или, ещё один пример - с другой стороны - 152фз о ПД - ну вот вообще никак на него не может повлиять на qa, ни qc, ни тестировщик - но, тем не менее этот закон есть и он-таки обеспечивает качество
А ещё есть потребители, которым абсолютно плевать и на линтеры, и на тестирование - они выставляют свои требования к качеству и, в зависимости от них, пользуются тем или другим приложением. И опять, эти внешние требования обеспечивают качество... А вот как вы этими требованиями будете управлять (контролировать их выполнение) - это уже другой вопрос - здесь и пригодится все, что бы знаете и о DoR, и о DoD, и о приемочных критериях...
Согласен, наймом и развитием мы тоже сильно влияем на качество. Более того, нам не нужно, чтобы конкретный Лёша становился Васей, нам нужно чтобы все наши сотрудники развивались. А как это сделать? Только работать с процессами: выстраивать качественный найм, создавать инструменты для развития внутри компании...
Я этим последние несколько лет и занимаюсь...
Звучит очень сомнительно, чтобы тестировщик занимался процессами найма и развития разработчиков. Да и к чему, если для этого есть HR?
И, да, никому не нужно, чтобы все его сотрудники "развивались" - нужно, чтобы они выполняли свою непосредственную работу как можно лучше. Если для этого сотрудника нужно "развить" - это хорошо, это правильно. А отвлекать человека от работы, непонятными активностями - это совсем неправильно
Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Вот в том-то и дело, что вектор движения обеспечения качества – выстроить процесс разработки таким образом, чтобы джун мог сделать не менее качественно, чем синьор. И не требовалось судорожно искать по рынку ещё одного, а то и сотни новых синьоров. Или тратить деньги на развитие своих джунов до уровня синьоров. Это совершенно невыгодно бизнесу в перспективе. На дистанции выгоднее построить конвейер, использовать в нём джунов, а получать качество, которое раньше получалось только при найме синьоров.
И чем лучше развивается культура обеспечения качества, тем дешевле строится такой конвейер, и тем меньше денег тратится на создание чего-то полезного. И тем больше синьоры занимаются ещё более интересными и сложными задачами.
Как бы там ни было - следуя одному и тому же техпроцессу, слесарь 6 разряда делает меньше брака, чем слесарь 4 🤷
Станок-упаковщик, который вообще не имеет ни грейда, ни интеллекта, ни опыта, но имеющий правильно составленную инструкцию для упаковки, делает меньше брака, чем человек-упаковщик ЛЮБОГО разряда
Диалог прям, как по нотам - "Цель" Голдратта вы конечно не читали))
Не имеющий грейда? Мне нужно 1000 упаковок в час, а ваш "станок" делает всего 100...
Не имеющий интеллекта? Для одной детали нужна упаковка вдоль, а для другой - поперек и идут они вперемешку...
Не имеющий опыта? Странно, но после месяца работы без обслуживания станок начал выдавать 50% брака))
Можно продолжить - то, что станок стоит денег, и если мне нужны 10 упаковок в день - он просто нерентабелен. Что его надо обслуживать и, зачастую, его обслуживание стоит дороже ручной упаковки и т.д.
Ваша проблема (не считая той, что вы почему то не смогли прочитать первые 10 страниц первого силлабуса istqb - и назначили тестировщегом человека, который занимается только выполнением тестов. Все остальные этапы тестирования - планирование, анализ, дизайн, реализация - вы почему-то решили отнести к QC)) - в том, что вы начали за здравие - QA это не то, чем в основном занимается тестировщик (и то, QA и QC пересекаются - вы же их изобразили даже не соприкасающимися), а кончили за упокой - у вас QA engineer - это тестировщег на стероидах - автоматизация, ci/cd и все такое... Т.е. ничего нового - это заблуждение из каждого утюга льется
Качество, в общем смысле ISO 9000-2015, откуда вы взяли ваши определения (может вы об этом и не знаете, но, они именно оттуда) - это не про IT, ПО редко выступает самоцелью - конечный пользователь, который платить деньги, вообще может ничего об этом не знать... У вас могуь быть и автотесты и ci/cd, и багов может вообще не быть - но, деньги пользователь почему-то несёт не вам....
В что почитать, чтобы прокачаться в QA?
К сожалению, мы пока не собирали какой-то список источников для этой задачи.
Но я бы рекомендовал попробовать разобрать процесс разработки на этапы, в каждом из этапов нашёл бы практики и техники, его обеспечивающие.
Из того, что прямо сейчас приходит на ум: изучите DoR и DoD, практики экстремального программирования, Три Амиго, стратегии ветвления, фича-флаги, Blue-Green деплои, trunk-based develompent. В принципе, в некоторых командах может потребоваться экспертиза настройки линтеров и статических анализаторов. Где-то - экспертиза организации код-ревью.
По ходу ещё наткнётесь на множество увлекательных практик и инструментов, которые могут помочь настроить процессы так, чтобы сделать разработку максимально быстрой и качественной.
Читайте классику
Деминг "Выход из кризиса". Если покажется сложным - начать можно с книги Генри Нива "Пространство доктора Деминга"
Элияху Голдратт - "Цель - 1, 2, 3", "Критическая цепь"
Листер и Демарко - "Дедлайн", "Человеческий фактор", "Вальсируя с медведями", "Балдеющие от адреналина"...
В целом QA это смесь тестировшика, дизайнера, аналитика, девопса. Все зависит от пула обязанностей.
1. Тестирование. Функционал был зафиксированным и рабочим, прорабатывались пограничные случаи, разные наборы параметров(таблицы решений).
2. ui\ux что бы иметь представление о правильном размещении элементов управления(с точки зрения фокуса пользователя) и минимизации действий для пользователя, а так же визуальная эстетика.
Как вариант - Не заставляйте меня думать.
3. Сбор требований и системный анализ.
Фиксация функциональных, нефункциональных требований..
Литература по uml, bpmn, общие статьи про базы данных, сетевые протоколы.
4. Документация. Внутренняя для разработчиков и внешняя. Контроль документации. Возможно даже внедрение определенных стандартов и гостов.
5. ci\cd в целом для удобства тестирования и доставки решений.
В общем виде qa инженер должен выстраивать процессы в команде из набора хороших практик.
По Вашей модели QA превращается в Scrum мастера, который сам не работает в QC и не видит, как его процессы работают изнутри.
Роли Scrum-мастер и QA-инженер действительно похоже, но Scrum-мастер не должен обладать инженерными навыками обеспечения качества. Условно линтер scrum-мастер не настроит. Более того, скрам мастерам зачастую рекомендуют не делать изменения самим, а подталкивать команду к изменениям. Так что разница есть
Так суть статьи, кажется, как раз в оом и заключается, что QA-инженеров нет, есть QA процесс который выстраивает вся команда и есть тестировщики, которые просто чуть больше в этот процесс могут быть вовлечены
Ну я и не сказал, что QA это Scram мастер. И смысл был не в том, чтобы определить что делает Scram мастер, а в том что будет делать QA после выстраивания процесса разработки? Сидеть и созерцать работу и ждать когда же появятся недоработки процессов?
Получается, QM в среднестатистическом российском IT это, так называемый, QA Lead?
Тут, кажется, от части дело в том, что нельзя специалиста назвать QA, как называют в повседневной речи, ведь QA это действительно процесс. Но если вспомнить, как полностью звучит название должности, то это будет не просто QA, а QA Engineer.
То есть, если перевести на русский, то мы получаем примерно инженер по обеспечению качества, как раз должность для человека который выстраивает процесс и привносит его в команду.
Спасибо за статью. Хорошо раскрыли и обосновали подход. Согласен в части разделения процесов и их нейминга. Но вот с точки зрения структуры и невозможности совмещения этих процессов в одном челоеке не согласен.
У меня за время работы устаялось такое понимание:
QA - проактивные действия по обеспечению качества
QC - реактивные действия по обеспечению качества
Считаю что QC не влияет на качетво, только если искуственно возвести границы вокруг этого процесса. Это равнозначно, если например сказать, что сдача медицинских анализов не влияет на здоровье. Да, напрямую не влияет, но влияет опосредованно. Но зачем об этом говорить? )). Баг-репорт найденный в процессе тестирования(QC) будет пофикшен и уверенность в качестве(QA) возрастет.
По-этому, ничего плохого в части нейминга QA для современного эффективного тестировщика не вижу. Он действительно может заниматься, тест-дизайном, тест-аналитикой, ручным и авто тестированием и выдвигать предложения по оптимизации процессов по недопущению багов. Для тестировщика, который пока еще не выполняет проактивные действия по предотвращению багов - есть хорошая точка роста и горизонт новых возможностей в плане использования процесса QA.
Ну и тут вопрос, можно ли одним процессом QA обойтись без без внутреннего QC? На мой взгляд нет. Просто процесс QC может размазываться по команде.
Без процесса QC обойтись кажется нельзя. Примеров таких я просто не знаю. А вот без отдельной роли, которая занимается только QC обойтись точно можно.
ну вот, т.е. мы пришли к тому, что QC-специалист - это будущий QA-инженер? Все правильно же называется, получается?
Не обязательно. Опять же, в статье мы пишем, что для выполнения процессов QC и QA требуются разные скиллы. Даже разные майндсеты, что бы это ни значило. Но определённо, я встречал большое количество тестировщиков, которым очень тяжело даётся QA. И огромное количество техлидов и тимлидов, например, которым это даётся сильно прощё.
Почему? Процессы QC и QA трубуют разных компетенций, разного склада ума. Если у вас душа лежит к контролю качества - так занимайтесь им.
Опять QC накурился и начал всем втирать что он тут самый главный за качество ... главное, чтобы когда проспится, не перепутал, на каком он проекте ... :)
quality assurance (QA)
1. part of quality management focused on providing confidence that quality requirements will be fulfilled
2. all the planned and systematic activities implemented within the quality system, and demonstrated as needed, to provide adequate confidence that an entity will fulfill requirements for quality
и дальше вольный перевод автора
QA – это процесс обеспечения качества.
Перевод настолько вольный, что даже трудно понять а как так то
Во-первых, никакого никакого обеспечения качества в оригинале нет. Есть некоторые активности (activities) которые нужны чтобы обеспечить уверенность в том (confidence ) что что-то там соответствует (fulfill) требованиям (requirements) в части качества (for quality)
Т.е. еще раз. никакого обеспечения качества, а только адекватная уверенност в том, что оно есть
Его цель – организовать процессы разработки (в широком смысле) таким образом, чтобы в результате получить продукт требуемого качества. То есть в QA входят мероприятия по предотвращению появления багов.
Дальше я так понимаю, уже было не остановить и мнящий себя тортом на минуту стал императором
Ну какая организация процесса разработки ... пока тимлиды вышли покурить на воздух? Серьезно?
Дальнейшее комментировать сложно, так как до такого полета фантазии я пока не готов, и наверное не в четверг, может завтра
----------------------
Не надо искать черную кошку в комнате без света, окон и дверей, особенно если ее там нет. задача QA/QC/test команды (по физ, хоть пусть будет написано на визитке самый главный менеджер по управлению качеством в компании) - обеспечить информацию о качетсве продукта и его соответствии требованиям.
Ну честно.
И главное - зачем?
У вас есть ваша задача, важная, ответственная, делайте ее.
О, харьковские пейзане подъехали)) Ну, как там клубника демократии? Колосится?
Вы, мсье, если уж взялись википедию цитировать - цитируйте полностью
"This defect prevention aspect of quality assurance differs from the defect detection aspect of quality control and has been referred to as a shift left since it focuses on quality efforts earlier in product development and production (i.e., a shift to the left of a linear process diagram reading left to right) and on avoiding defects in the first place rather than correcting them after the fact"
В результате прочтения вашего комментария сложилось ощущение, что вы неправильно поняли статью или прочитали её по диагонали.
В статье прямым текстом говорится, что задача QC – обеспечить информацию о качестве продукта и его соответствии требованиям.
Вы пишете тоже самое, только почему-то со статьёй не соглашаетесь, это забавно)
А дальше про QA? До QC все было прекрасно, я не спорю, но дальше что-то пошло не так, но я планирую "подзакинуться" в пятницу и возможно в этом момент меня настигнет мысденное единение с автором :)
Смысл статьи, если грубо, в том, что QC (то, чем занимаются преимущественно тестировщики) не имеет никакого отношения к QA.
> Ну какая организация процесса разработки ... пока тимлиды вышли покурить на воздух? Серьезно?
И об этом мы говорим. О том, что тимлид в том числе занимается QA, и, как правило, куда в большей степени, чем тестировщик. Но почему-то именно тестировщиков все называют QA. Эту "несправедливость" мы статьёй и хотим попытаться исправить.
Дело в том, что даже QA тимлид не занимается
QA – это процесс обеспечения качества. Его цель – организовать процессы разработки (в широком смысле) таким образом, чтобы в результате получить продукт требуемого качества. То есть в QA входят мероприятия по предотвращению появления багов.
Не, он может думать что занимается ... как к примеру, тут статья недавно пробегала, про тимлидов, которые почти менеджеры проектов :)
Но в реальности нет от слова совсем
Но я допускаю, что есть такие лиды, которые давно переросли позицию и действительно что-то такое делают, но ... это лишь исключение, на которм нельзя строить обобщения
Спасибо за статью, расписано хорошо.
Прошерстили весь интернет, но не нашли действительно понятных материалов по этой теме. Вот в такую ситуацию попали и мы. Потому мы решили написать статью, чтобы помочь всем нам разобраться в том, что такое QA, в чём отличие от QC, и где среди этого всего находится тестировщик.
очень смешно, учитывая что это базовейшая база, которая в любой литературе и на любых курсах сразу с первых же страниц в лицо прилетает.
А называть я себя буду так, как хотят рекрутеры. хотят QA - буду QA, хотят QC - буду QC, хотят тестировщиком - буду тестировщиком. Могу быть еще тостером, куа макакой, ручником, автоматоном, асессором - как будет называться штатная единица с описанием вакансии, где перечислены близкие для меня навыки, так и я буду называться.
Во вторых - зачем вы задаете вопросы такие вопросы на собеседовании? вам спросить нечего по профилю работы? по опыту работу кандидата? терминологическое словоблудие, особенно привязанное к istqb силлабусу, это огромный такой ред флаг размером с эверест. Могу предположить, что вы собеседуете в галеру, где главный навык гребца быть натасканным на собесы по книжке, других причин, почему человек может спрашивать не про работу, а про слова, я не вижу. Я шестой год в тестировании, знание терминов мне и моим коллегам и всем моим знакомым тестировщикам пригодилось только вот для прохождения таких невнятных шаблонных собесов, в работе ноль раз, на работе задачи закрывают обычно
По поводу "называть себя буду так, как хотят рекрутеры". Вы путаете причину и следствие, к сожалению. Не рекрутеры придумали называть тестировщиков QA, а сами тестировщики. Как-то странно плясать под дудку тех, кто пляшет под вашу дудку.
По поводу того, что мы спрашиваем на собеседованиях: в статье русским языком написано, что мы считаем это не просто терминологической путаницей. Мы никогда не спрашиваем на собеседованиях определения терминов. Мы выясняем, умеет ли человек в анализ (т.е. отделять одно от другого), понимает ли, что такое "роль", рефлексирует ли он вообще о том, чем он занимается по жизни, или просто кнопки жмёт. И да, в хорошо настроенных процессах всё это требуется знать для качественной работы. Жаль, что вам не доводилось в подобных ситуациях оказываться
очень смешно, учитывая что это базовейшая база, которая в любой литературе и на любых курсах сразу с первых же страниц в лицо прилетает.
В хорошей литературе действительно пишут в основном правильно, вот только не в каждый книжке вы найдёте определение процесса QA.
А вот с курсами ситуация хуже. В описании многих курсов вы увидите, что понятия QA и тестирование перепутаны
Во вторых - зачем вы задаете вопросы такие вопросы на собеседовании?
Компетенция в обеспечении качества для нас важна. Очевидно, что сотрудники, которые способно позитивно влиять на команду и на процессу ценны. Поэтому мы говорим о опыте кандидата в сфере обеспечения качества
Как может QC не является частью QA, если QA это совокупность всех мероприятий на жизненном цикле продукта для обеспечения требуемого качества, в том числе контроль качества.
Да, разделение этих мероприятий по команде может различным, в проектах и тестирование чего только не встретишь. Поэтому однозначно говорить странно, можно еще sdet-ов и qe вспомнить.
QA это же набор мероприятия\подход, как и DevOps. Но никто не скажет, что деплой в него не входит.
Почему бы не обратиться к материалам ISTQB, где прописано кто что и как
Почему бы не обратиться к материалам ISTQB, где прописано кто что и как
Это все просто синонимы, ни чем все это не отличается. Типа как программист и разработчик.
о, новый взгляд)
по-моему автор статьи хотел скзать что-то типо "вот смари - у тя в команде разные челики есть, одни тестируют, другие код пишут, а качество это вообще ваша общая тема, типо вы все за него отвечаете, ну и кароче получается что QA это типо вы все вместе делаете всякие штуки чтобы максимум проблем еще до тестирования устранить"
в целом все верно, только есть еще "специализация", типо в команде много разных людей, каждый специализируется на чем-то своем (в t-shape вот эта длинная палка - специализация как раз), и вот есть один чел (или 2+) который специализируется на обеспечении качества, он видит какие "проблемы" могут возникать, обращает на это внимание команды, и они договариваются как этих проблем избежать. (вообще каждый член команды выполняет какие-то задачи по обеспечению качества и без участия QA специалиста, но это не значит что все сразу записывают себе специализацию на обеспечении качества.
Совершенно верно!
То, что тестировщиков стали называть QA – как раз результат того, что именно тестировщики стали чаще других ролей специализироваться на обеспечении качества. Но, к сожалению, в итоге это привело к тому, что всех тестировщиков стали называть QA. С этим мы и хотим попробовать бороться.
Спасибо большое за ваш комментарий!
Статья понравилась, интересное чтиво, очень актуально, спасибо!
Не сочтите за придирку к словам, может тут разный контекст просто присутствует, но
Мы считаем, что очень важно понимать, что измеряя качество, мы не влияем на него.
или выше речь идет про качество продукта, а не конкретных задач/фич (как ниже)?
хотя фичи/задачи = продукт)
чуть далее
Начнём с Бориса, который теперь в каждой итерации тестирует требования: он занимается процессом контроля качества. Он влияет на качество конкретных задач/фич.
контроля = измерения?
По итогу, через контроль качества мы можем влиять на качество?
Извините, спасибо)
Во втором случае мы скорее хотели обозначить отличие в областях применимости результата процессов QC и QA, поэтому выразились так. Благодаря вашему комментарию поняли, что не совсем точно. Спасибо, очень дельное замечание!
> По итогу, через контроль качества мы можем влиять на качество?
Контроль качества помогает влиять на качество, но сам по себе является лишь лакмусовой бумажкой.
Мы считаем, что очень важно понимать, что измеряя качество, мы не влияем на него.
или выше речь идет про качество продукта, а не конкретных задач/фич (как ниже)?
Тут просто. Каждый раз, когда мы измеряем качество, находим баги или успешно проводим тесты мы не увеличиваем ни качество продукта вообщем, ни качество конкретной итерации.
Качество итерации вырастет, если:
1) Продакт / заказчик решит что надо исправить баг (не всегда так происходит)
2) Разработчик исправит этот баг
Контролируя качество мы создаём артефакты, которые используются в процессе обеспечения качества
Перестань называть себя QA