Или как понять что такое 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. Что это такое, предлагаем вам разобраться самостоятельно. Пишите в комментариях ваши идеи трактовки данного термина.
Комментарии (30)
remanam
04.07.2024 08:44Спасибо большое за статью! Эта тема реально абсолютно нигде не раскрыта в нормальном виде.
Ivan_Pod
04.07.2024 08:44Да, эта аббревиатура уже настолько навязала в зубах, что уже начали придумывать всякие эвфемизмы для неё - например 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Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Вот в том-то и дело, что вектор движения обеспечения качества – выстроить процесс разработки таким образом, чтобы джун мог сделать не менее качественно, чем синьор. И не требовалось судорожно искать по рынку ещё одного, а то и сотни новых синьоров. Или тратить деньги на развитие своих джунов до уровня синьоров. Это совершенно невыгодно бизнесу в перспективе. На дистанции выгоднее построить конвейер, использовать в нём джунов, а получать качество, которое раньше получалось только при найме синьоров.
И чем лучше развивается культура обеспечения качества, тем дешевле строится такой конвейер, и тем меньше денег тратится на создание чего-то полезного. И тем больше синьоры занимаются ещё более интересными и сложными задачами.
QANovikov
04.07.2024 08:44По Вашей модели QA превращается в Scrum мастера, который сам не работает в QC и не видит, как его процессы работают изнутри.
valera-glukhovtsev Автор
04.07.2024 08:44Роли Scrum-мастер и QA-инженер действительно похоже, но Scrum-мастер не должен обладать инженерными навыками обеспечения качества. Условно линтер scrum-мастер не настроит. Более того, скрам мастерам зачастую рекомендуют не делать изменения самим, а подталкивать команду к изменениям. Так что разница есть
Its_Not_Nickname
04.07.2024 08:44Так суть статьи, кажется, как раз в оом и заключается, что QA-инженеров нет, есть QA процесс который выстраивает вся команда и есть тестировщики, которые просто чуть больше в этот процесс могут быть вовлечены
QANovikov
04.07.2024 08:44Ну я и не сказал, что QA это Scram мастер. И смысл был не в том, чтобы определить что делает Scram мастер, а в том что будет делать QA после выстраивания процесса разработки? Сидеть и созерцать работу и ждать когда же появятся недоработки процессов?
valera-glukhovtsev Автор
04.07.2024 08:44Если QA-инженер смог всё сделать в одной команде, он может пойти в другую. Компании развиваются, команд становится больше, светлые головы везде нужны
valera-glukhovtsev Автор
04.07.2024 08:44В этом они похожи с Scram-мастером. Цель хорошего Scram-мастера - стать не нужным.
Rina294
04.07.2024 08:44Получается, QM в среднестатистическом российском IT это, так называемый, QA Lead?
Its_Not_Nickname
04.07.2024 08:44+1Тут, кажется, от части дело в том, что нельзя специалиста назвать QA, как называют в повседневной речи, ведь QA это действительно процесс. Но если вспомнить, как полностью звучит название должности, то это будет не просто QA, а QA Engineer.
То есть, если перевести на русский, то мы получаем примерно инженер по обеспечению качества, как раз должность для человека который выстраивает процесс и привносит его в команду.
valera-glukhovtsev Автор
04.07.2024 08:44Ох, да, думали добавить в эту статью и это рассуждение. Но тут есть и "QA-инженер", и "специалист по обеспечению качества" и что-нибудь ещё...
А ведь между "инженер" и "специалист" есть разница, и её тоже надо объяснять... Короче прям отдельная тема)Its_Not_Nickname
04.07.2024 08:44В таком контексте, тогда, с вами соглашусь. Далеко не каждый кто работает тестировщиком и/или называет себя QA Engineer действительно является инженером. Это может быть сотрудник, который занимается контролем качества, но не стремится к выстраиванию глобального процесса качества как такового
LiberumQA
04.07.2024 08:44Спасибо за статью. Хорошо раскрыли и обосновали подход. Согласен в части разделения процесов и их нейминга. Но вот с точки зрения структуры и невозможности совмещения этих процессов в одном челоеке не согласен.
У меня за время работы устаялось такое понимание:
QA - проактивные действия по обеспечению качества
QC - реактивные действия по обеспечению качества
Считаю что QC не влияет на качетво, только если искуственно возвести границы вокруг этого процесса. Это равнозначно, если например сказать, что сдача медицинских анализов не влияет на здоровье. Да, напрямую не влияет, но влияет опосредованно. Но зачем об этом говорить? )). Баг-репорт найденный в процессе тестирования(QC) будет пофикшен и уверенность в качестве(QA) возрастет.
По-этому, ничего плохого в части нейминга QA для современного эффективного тестировщика не вижу. Он действительно может заниматься, тест-дизайном, тест-аналитикой, ручным и авто тестированием и выдвигать предложения по оптимизации процессов по недопущению багов. Для тестировщика, который пока еще не выполняет проактивные действия по предотвращению багов - есть хорошая точка роста и горизонт новых возможностей в плане использования процесса QA.
Ну и тут вопрос, можно ли одним процессом QA обойтись без без внутреннего QC? На мой взгляд нет. Просто процесс QC может размазываться по команде.valera-glukhovtsev Автор
04.07.2024 08:44Без процесса QC обойтись кажется нельзя. Примеров таких я просто не знаю. А вот без отдельной роли, которая занимается только QC обойтись точно можно.
Batalmv
04.07.2024 08:44+2Опять 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 команды (по физ, хоть пусть будет написано на визитке самый главный менеджер по управлению качеством в компании) - обеспечить информацию о качетсве продукта и его соответствии требованиям.
Ну честно.
И главное - зачем?
У вас есть ваша задача, важная, ответственная, делайте ее.
Ivan_Pod
04.07.2024 08:44О, харьковские пейзане подъехали)) Ну, как там клубника демократии? Колосится?
Вы, мсье, если уж взялись википедию цитировать - цитируйте полностью
"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"
9teen
04.07.2024 08:44В результате прочтения вашего комментария сложилось ощущение, что вы неправильно поняли статью или прочитали её по диагонали.
В статье прямым текстом говорится, что задача QC – обеспечить информацию о качестве продукта и его соответствии требованиям.
Вы пишете тоже самое, только почему-то со статьёй не соглашаетесь, это забавно)
dabel1k0v
Тестирование это база, всё остальное процессы, которые может использовать тестировщик, о чём вы расписали в статье. Не выдумывайте. Ярлыки нужны, чтобы цену набить, ну или как-то отделить квалификацию одного тостера от другого. Это в любом случае должен быть инженер, который понимает не только в тестировании.
9teen
Привет! А почему вдруг грейдов перестало быть достаточно для отделения квалификации одного тостера от другого?)
dabel1k0v
Не знаю, спросите у HR
valera-glukhovtsev Автор
В том то и дело, что мы относимся к словам QA и QC не как к "ярлыкам". Для нас это процессы, которыми мы занимаемся. И занимаемся мы ими не чтобы набить цену, а чтобы приносить пользу)
dabel1k0v
Да, эту мысль я чуть позже уловил (после первого комментария). Теперь эту мысль донести до HR и, возможно, они наймут нужных людей.