Перестань называть себя QA
Или как понять что такое QA и QC и не поехать QQхой
Авторы: Валерий Глуховцев, Евгений Сабиров
Представьте себе ситуацию: вы провели больше 200 технических интервью, и в подавляющем большинстве из них интервьюируемые давали весьма невнятные ответы в одной и той же теме. Вы, естественно, заподозрили, что здесь что-то неладно, и решили проверить себя. Прошерстили весь интернет, но не нашли действительно понятных материалов по этой теме. Вот в такую ситуацию попали и мы. Потому мы решили написать статью, чтобы помочь всем нам разобраться в том, что такое QA, в чём отличие от QC, и где среди этого всего находится тестировщик.
Разобраться — это, конечно, не самоцель. Не самоцель и разобраться, чтобы правильно отвечать на собеседованиях. Мы убеждены, что подмена понятий «QA» и «тестирование» — это не просто терминологическая путаница, а серьёзная проблема, мешающая развиваться как конкретным специалистам, так и всей индустрии в целом. Огромное количество митапов, конференций (даже федерального уровня) содержат в своём названии заветные буквы QA, но при этом готовят контент для тестировщиков. Огромное количество образовательных площадок называют свои курсы «QA-инженер», хотя готовят в лучшем случае тестировщиков, если не асессоров. Между тем, QA — это вообще не о тестировании в каком бы то ни было смысле, и сейчас мы попробуем раскрыть эту мысль.
Начнём с картинки, которую вы все наверняка видели:
Самый распространённый вариант и, спойлер, неверный
Здесь изображено три процесса: Testing, Quality Control и Quality Assurance. Это не конкретные люди/должности, а именно процессы — чуть позже мы раскроем, почему это важно понимать.
Testing — самое простое понятие из трёх. Testing — это в буквальном смысле исполнение проверок. Если в вашей команде есть тестировщик, то именно он, как правило, и занимается этим процессом. Однако существуют компании, в которых этим процессом занимается отдельная роль, которую часто называют «асессор». Асессор берёт уже кем-то спроектированный план проверок, осуществляет его и предоставляет отчёт.
QC
Теперь разберёмся с тем, что такое QC, для этого посмотрим на определения из нескольких источников.
ISTQB Foundation Level Syllabus2023 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. Что это такое, предлагаем вам разобраться самостоятельно. Пишите в комментариях ваши идеи трактовки данного термина.
