Или как понять что такое QA и QC и не поехать QQхой
Авторы: Валерий Глуховцев, Евгений Сабиров
Представьте себе ситуацию: вы провели больше 200 технических интервью, и в подавляющем большинстве из них интервьюируемые давали весьма невнятные ответы в одной и той же теме. Вы, естественно, заподозрили, что здесь что-то неладно, и решили проверить себя. Прошерстили весь интернет, но не нашли действительно понятных материалов по этой теме. Вот в такую ситуацию попали и мы. Потому мы решили написать статью, чтобы помочь всем нам разобраться в том, что такое QA, в чём отличие от QC, и где среди этого всего находится тестировщик.
Разобраться — это, конечно, не самоцель. Не самоцель и разобраться, чтобы правильно отвечать на собеседованиях. Мы убеждены, что подмена понятий «QA» и «тестирование» – это не просто терминологическая путаница, а серьёзная проблема, мешающая развиваться как конкретным специалистам, так и всей индустрии в целом. Огромное количество митапов, конференций (даже федерального уровня) содержат в своём названии заветные буквы QA, но при этом готовят контент для тестировщиков. Огромное количество образовательных площадок называют свои курсы «QA-инженер», хотя готовят в лучшем случае тестировщиков, если не асессоров. Между тем, QA – это вообще не о тестировании в каком бы то ни было смысле, и сейчас мы попробуем раскрыть эту мысль.
Начнём с картинки, которую вы все наверняка видели:
Здесь изображено три процесса: Testing, Quality Control и Quality Assurance. Это не конкретные люди/должности, а именно процессы – чуть позже мы раскроем, почему это важно понимать.
Testing – самое простое понятие из трёх. Testing – это в буквальном смысле исполнение проверок. Если в вашей команде есть тестировщик, то именно он, как правило, и занимается этим процессом. Однако существуют компании, в которых этим процессом занимается отдельная роль, которую часто называют «асессор». Асессор берёт уже кем-то спроектированный план проверок, осуществляет его и предоставляет отчёт.
QC
Теперь разберёмся с тем, что такое QC, для этого посмотрим на определения из нескольких источников.
ISTQB Foundation Level Syllabus 2023 Russian:
Контроль качества (QC) — это корректирующий подход, ориентированный на продукт, который сосредотачивается на действиях, поддерживающих достижение надлежащего уровня качества.
ISO/IEC/IEEE 24765:2017:
quality control (QC)
1. set of activities designed to evaluate the quality of developed or manufactured products
2. monitoring service performance or product quality, recording results, and recommending necessary changes
В них QC определяется как процесс, цель которого – дать обратную связь о техническом состоянии тестируемого продукта. Процесс QC содержит в себе Testing. Но, помимо него, также включает в себя подготовку проверок, метрик тестирования, тестовых данных и прочих артефактов, которые упрощают измерение качества или передачу обратной связи. Так, например, написание тест-кейсов и написание автоматизированных тестов следует относить именно к процессу контроля качества (QC).
Многие из интервьюируемых, отвечая на вопрос «А в чём цель этапа контроля качества или тестирования?», дают ответ «Сделать продукт более качественным» или различные вариации этого ответа.
Чтобы понять, почему это некорректно, можно представить, что человек, осуществляющий QC держит в руках градусник или линейку. От измерений ни температура, ни длина объекта не изменяются. Мы считаем, что очень важно понимать, что измеряя качество, мы не влияем на него. Считать, что обнаружив баг, мы улучшим качество продукта – некорректно. Баг от этого никуда не делся, а работы по его исправлению – точно не составляющая процесса контроля качества.
Более того, измерив качество, мы не принимаем решений о том, достаточный ли уровень качества у тестируемого продукта. Это обязанность других процессов, других ролей. Наша задача при исполнении процесса QC – дать необходимую информацию для принятия решения о релизе или его переносе.
Многие из интервьюируемых, отвечая на вопрос «Какие практики обеспечения качества (QA) ты знаешь?» отвечают «Тестирование требований». Но, учитывая предыдущие умозаключения, становится очевидно, что это тоже некорректный ответ. Измерять качество можно на разных этапах. И тестирование требований – точно такой же процесс контроля качества, просто он относится к требованиям, а не к исполняемому коду.
QA
Здесь возникает закономерный вопрос: а что тогда является обеспечением качества? Сперва, конечно, взглянем на определения.
ISTQB Foundation Level Syllabus 2023 Russian:
Обеспечение качества (QA) — это превентивный подход, ориентированный на процесс, который сосредотачивается на внедрении и улучшении процессов. Он предполагает, что если правильно следовать хорошему процессу, то будет создан хороший продукт.
ISO/IEC/IEEE 24765:2017:
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 – это процесс обеспечения качества. Его цель – организовать процессы разработки (в широком смысле) таким образом, чтобы в результате получить продукт требуемого качества. То есть в QA входят мероприятия по предотвращению появления багов.
Важное отличие процессов QA и QC заключается в зоне применимости результатов этих процессов. Результаты QC можно увидеть в конкретной итерации продукта (релизе), а вот результаты процесса QA оказывают влияние на качество во всех последующих итерациях.
Более того, процесс QA применим к процессу QC – мы можем внедрять изменения в процесс контроля качества для того, чтобы результаты этого процесса становились более качественными.
Примеры процессов QA и QC
Всё ещё ничего не понятно? Тогда приведём несколько примеров.
Представьте себе команду, которая занимается продуктовой разработкой. Антон (участник этой команды) обратил внимание на то, что задачи, над которыми он работает, часто содержат неоднозначные и неполные требования, которые приходится регулярно уточнять у автора задачи. Антон составил DoR (про Definition of Ready вы можете почитать тут) и согласовал его с командой и заказчиками. Также Антон договорился, что он и Борис (другой участник команды) будут тестировать требования перед тем, как задача попадёт к разработчику. Кто и каким процессом здесь занимался?
Начнём с Бориса, который теперь в каждой итерации тестирует требования: он занимается процессом контроля качества. Он влияет на качество конкретных задач/фич. А что же Антон? Сначала Антон внедрил DoR и процесс тестирования требований – он занимался обеспечением качества. В результате он повлиял на качество всех последующих задач/фич. После этого, тестируя требования, Антон, как и Борис, участвует в контроле качества.
Ещё один пример. Есть команда, которая давно работает вместе. Они регулярно проводят ретроспективы и следят за метриками. За прошедший год они настроили CI, сформировали DoR и организовали код-ревью. Все эти изменения предлагали и осуществляли разные участники. Есть ли в этой команде кто-то, кого мы можем назвать QA? Нет. Зато в ней есть процесс QA, и им занимается вся команда.
Третий пример: Гриша пришёл в команду А. В ней работают аналитик Дима и асессор Егор. Дима пишет требования, ТЗ и проверки, а Егор проводит проверки. Гриша заметил, что Егор хорошо развивается в тестировании, а Диме не хватает времени заниматься анализом и составлением проверок одновременно. Гриша помог ребятам изменить процессы: теперь Егор самостоятельно подготавливает и проводит тестирование, а Дима занимается только аналитикой и стал успевать выполнять все свои задачи. Позднее Гриша ушёл в команду Б и помог ребятам улучшить процессы и там, а после повторял это всё в новых и новых командах.
В этом примере Егор занимался процессом «Testing», а потом стал заниматься контролем качества. Гриша же занимается только процессом QA, не занимаясь при этом QC.
Четвёртый пример: Женя заметил, что в тестируемом им продукте с завидной регулярностью появляется один и тот же баг – бесконечное зависание программы. Причём появляется он после изменений, которые вносят совершенно разные разработчики. Покопавшись в логах и разобрав ситуацию с одним из программистов, стало ясно, что ошибки возникают из-за циклических зависимостей в коде. Женя настроил линтер так, чтобы он сканировал код на наличие таких проблем и сообщал об этом разработчику до того, как тот будет сливать изменения на тестовый контур.
В этом примере мы видим, как в процессе QA могут использоваться результаты QC. На практике это случается действительно часто, и это одна из причин, почему тестировщиков стали называть QA.
Хорошо, а почему же вредно называть тестировщиков – «куэями» и наоборот? Потому что, называя процесс контроля качества – QA, мы обесцениваем важность такого процесса, как обеспечение качества. Мы как бы закрываем глаза на его существование. А между тем, это отдельная большая область знаний, в которой следует разбираться.
Чтобы хорошо исполнять процесс QA, нужно знать, что такое линтер, что такое code-review, как правильно составлять DoR, как это всё правильно внедрить и организовать в команде, нужно понимать, что такое CI, что такое CD и почему пора перестать писать их через косую черту где попало. Для того, чтобы быть QA-инженером, недостаточно просто пройти курс по техникам тест-дизайна и заниматься ручным тестированием веб-приложений. Этого может быть достаточно для того, кто занимается контролем качества.
Поэтому, если кто-то занимается только тем, что описано в нашей статье как «контроль качества», не стоит называть его «куэем» или «QA-инженером». Для удобства мы можем договориться, что «тестировщик» – то же самое, что и «специалист по контролю качества». Называйте таких специалистов тестировщиками или QC-инженерами.
И изучайте новое, если вам интересно заниматься обеспечением качества. Ведь чем больше людей занимается QA, тем меньше людей потребуется для исполнения QC. И однажды мы окажемся в мире, в котором тестировщиков будет также мало, как и специалистов ОТК (отдел технического контроля) на заводах. Для нас это звучит как цель, к которой можно стремиться.
Подводя итог, картинка из начала статьи, по нашему мнению, должна выглядеть так:
QC не является частью QA. Как вы поняли из примеров, эти процессы тесно связаны, но это отдельные процессы. Что важнее, для того чтобы заниматься данными процессами, нужны разные навыки и разный образ мышления.
Ну и появилась новая аббревиатура – QM! Расшифровывается как Quality Management. Что это такое, предлагаем вам разобраться самостоятельно. Пишите в комментариях ваши идеи трактовки данного термина.
Комментарии (54)
remanam
04.07.2024 08:44+2Спасибо большое за статью! Эта тема реально абсолютно нигде не раскрыта в нормальном виде.
Ivan_Pod
04.07.2024 08:44+1Да, эта аббревиатура уже настолько навязала в зубах, что уже начали придумывать всякие эвфемизмы для неё - например quality assistance - "содействие в обеспечении качества"))
Поэтому, вопрос действительно важный, но... Не докрутили вы, ребят. Даже, совсем наоборот - пошли в какие-то дебри...
Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Поэтому первый вопрос, который мы должны решить - не как внедрить ci/cd или в линтер чего нового запихнуть - а как сделать так, чтобы Леша стал Васей. Если есть деньги и нет времени - Лёшу можно уволить и нанять ещё одного Васю - и, да, это будет самым что ни на есть обеспечением качества. Или, Лёшу можно научить - на рабочем месте, что всегда и ставил во главу угла "папа" качества в его современном понимании У.Э.Деминг
Или, ещё один пример - с другой стороны - 152фз о ПД - ну вот вообще никак на него не может повлиять на qa, ни qc, ни тестировщик - но, тем не менее этот закон есть и он-таки обеспечивает качество
А ещё есть потребители, которым абсолютно плевать и на линтеры, и на тестирование - они выставляют свои требования к качеству и, в зависимости от них, пользуются тем или другим приложением. И опять, эти внешние требования обеспечивают качество... А вот как вы этими требованиями будете управлять (контролировать их выполнение) - это уже другой вопрос - здесь и пригодится все, что бы знаете и о DoR, и о DoD, и о приемочных критериях...
valera-glukhovtsev Автор
04.07.2024 08:44Согласен, наймом и развитием мы тоже сильно влияем на качество. Более того, нам не нужно, чтобы конкретный Лёша становился Васей, нам нужно чтобы все наши сотрудники развивались. А как это сделать? Только работать с процессами: выстраивать качественный найм, создавать инструменты для развития внутри компании...
Я этим последние несколько лет и занимаюсь...Ivan_Pod
04.07.2024 08:44Звучит очень сомнительно, чтобы тестировщик занимался процессами найма и развития разработчиков. Да и к чему, если для этого есть HR?
И, да, никому не нужно, чтобы все его сотрудники "развивались" - нужно, чтобы они выполняли свою непосредственную работу как можно лучше. Если для этого сотрудника нужно "развить" - это хорошо, это правильно. А отвлекать человека от работы, непонятными активностями - это совсем неправильно
valera-glukhovtsev Автор
04.07.2024 08:44К сожалению ИТ эта область в которой нужно развиваться, чтобы оставаться на том же уровне. Вместе с индустрией. Иначе просто отстанем.
И я не говорил что занимаюсь этим один) Просто развивать надо в том числе и тестировщиков, а у кого как не у тестировщиков должна быть эта экспертиза?
9teen
04.07.2024 08:44+1Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Вот в том-то и дело, что вектор движения обеспечения качества – выстроить процесс разработки таким образом, чтобы джун мог сделать не менее качественно, чем синьор. И не требовалось судорожно искать по рынку ещё одного, а то и сотни новых синьоров. Или тратить деньги на развитие своих джунов до уровня синьоров. Это совершенно невыгодно бизнесу в перспективе. На дистанции выгоднее построить конвейер, использовать в нём джунов, а получать качество, которое раньше получалось только при найме синьоров.
И чем лучше развивается культура обеспечения качества, тем дешевле строится такой конвейер, и тем меньше денег тратится на создание чего-то полезного. И тем больше синьоры занимаются ещё более интересными и сложными задачами.
dabel1k0v
Тестирование это база, всё остальное процессы, которые может использовать тестировщик, о чём вы расписали в статье. Не выдумывайте. Ярлыки нужны, чтобы цену набить, ну или как-то отделить квалификацию одного тостера от другого. Это в любом случае должен быть инженер, который понимает не только в тестировании.
9teen
Привет! А почему вдруг грейдов перестало быть достаточно для отделения квалификации одного тостера от другого?)
dabel1k0v
Не знаю, спросите у HR
jinn50k
Это ситуация как с админами, лычка DevOps добавляет в уровень твоей компенсации ровно нолик справа, хотя казалось бы, грейды одинаковые.
valera-glukhovtsev Автор
В том то и дело, что мы относимся к словам QA и QC не как к "ярлыкам". Для нас это процессы, которыми мы занимаемся. И занимаемся мы ими не чтобы набить цену, а чтобы приносить пользу)
dabel1k0v
Да, эту мысль я чуть позже уловил (после первого комментария). Теперь эту мысль донести до HR и, возможно, они наймут нужных людей.
voldemar_d
от микроволновки? ;)
(простите, не удержался)