Проблема с понятием QA

Сейчас тестировщики называют себя QA-инженерами, а на название “тестировщик” могут даже огрызнуться. В большинстве случаев это будет в шутку, но некоторые всерьёз начинают говорить про обеспечение качества, а не простое тестирование.

И это нормально, если об этом говорит человек с уровнем сеньора. Но когда такое заявляет джун или даже мидл, который только научился автоматизировать, то слова об обеспечении качества воспринимаются странно. Если уж вдаваться в термины, то рядовые миддлы по знаниям где-то между тестировщиками и QC (Quality Control) инженерами, но никак не QA.

Между полноценным обеспечением качества и обычным тестированием огромная пропасть по навыкам и зонам ответственности – чтение и написание кода, анализ требований, настройка процессов, выход за рамки отдела тестирования и т.д. и т.п. А ещё обеспечивать качество невозможно, если находиться только на одном этапе разработки – после написания кода и до релиза.

У проблемы наименования есть ещё одна причина – упрощение понятия QA. Нет градации – тестировщик, QC, QA; есть градация джун QA, миддл QA, сеньор QA.

Но зачем мы вообще говорим об этом? Какая разница, как называть человека, если это всем понятно?

Как по мне, разница есть. Когда человек только видит горизонт QA, он начинает задумываться, что это понятие действительно значит и каких компетенций ему не хватает, чтобы действительно обеспечивать качество, а не просто тестировать.

Но, несмотря на всё вышесказанное, я за то, чтобы оставить аббревиатуру QA и называть тестировщиков QA-инженерами. С одним но – Quality Assurance заменить на Quality Assistance.

Quality Assistance

Это понятие, насколько знаю, ввели ребята из Atlassian. Для них Quality Assistance – это набор практик, помогающий сместить ответственность за качество с тестировщиков на всю команду. Вот статья, где такой подход сравнивается с традиционным и приводится описание некоторых практик (а ещё там есть продолжение, тоже прочтите).

Эти практики хороши и в отдельности, если вы не хотите полностью менять процессы в компании. Например, догфудинг – использование дев-сборок приложения сотрудниками – помогает находить проблемы до релиза за счёт внутреннего краудтестинга. Или QA-кикоффы – когда разработчик обсуждает с QA потенциальные проблемы ещё до написания кода.

Но я всё же хочу поговорить не о конкретном подходе или практиках, а о смене парадигмы мышления от обеспечения качества до содействия ему. Содействие качеству работает наравне с обеспеченим на всех этапах, но не накладывает груз “фантомной” ответственности (см. предыдущий пост). Помогая аналитикам и тестируя требования, тестировщики не становятся ответственными за качество требований. То же самое и с внедрением инженерных практик – за качество кода ответственность продолжают нести разработчики.

Чтобы содействовать качеству, достаточно минимальных навыков тестирования, но сфокусированных не только на новой функциональности и регрессе. При обычном тестировании мы сверяем ожидаемое поведение с реальным, при содействии мы выходим за эти рамки и начинаем подключаться к каждому этапу. Начинаем задавать вопросы, а точно ли ожидаемое поведение корректное? А можно ли повлиять на реальное поведение раньше пришедшей в релиз сборки? Как помочь разработчикам выдавать крутой результат как можно раньше?

Эти вопросы задают и обычные тестировщики, ведь мыслить такими категориями учит практически каждая статья. Но эти статьи обычно не выходят за рамки этапа тестирования, за рамки роли тестировщика. Всё заканчивается на автоматизации, возможно, анализе требований по очередной аббревиатуре.

Остаётся ещё вопрос – когда всем этим заниматься? Реалии таковы, что у обычного тестировщика может висеть куча задач на тестировании, а ещё нужно же писать тест-кейсы и документацию обновлять. Ответ – идти на компромиссы и договариваться о высвобождении времени за счёт определённых рисков. Одновременно с этим пытайтесь внедрить практики, уменьшающие риски и увеличивающие ваше время: первичное тестирование разработчиками, Definition of Ready и Definition of Done, упрощение настроек тестового окружения и т.д..

Выход из зоны “тестирования”

Раньше я считал, что теория и уж тем более терминология второстепенны. А потом я увидел ребят, которые практиковались как бешеные, но не видели ничего дальше своего станка. Им было плевать на теорию, на то, куда двигаться дальше, какие у них компетенции и что это вообще такое. Термины они вспоминали только перед собеседованием. Они знали про автотесты, они пытались в них, и у них даже получалось. Только это были UI-тесты, на Selenium (а что, бывает что-то ещё?), когда у разработчиков покрытие юнитами было 0,01% и то, если повезёт.

Сейчас таких ребят всё меньше и меньше, благо материалы для новичков стали со временем намного лучше. Тестировщики пытаются идти на контакт с разработчиками, договариваются с аналитиками, но всё равно держатся в своей зоне ответственности – тестировании после разработки и до релиза. Со временем эта зона ответственности превращается в зону комфорта. Слова из Agile про взаимозаменяемость участников команды воспринимаются как сказки.

Пора выходить из зоны комфорта. Не надо ждать, когда вы сможете обеспечивать качество – начинайте содействовать ему сейчас. Среди 20 тасок найдётся та, с тестированием которой поможет разработчик и напишет вам в помощь скрипт или метод API для ускорения рутины. Придите на планирование спринта, на обсуждение фич и задавайте вопросы. Узнайте про метрики, алерты и мониторинг в целом. Спуститесь в автоматизации на уровень ниже, а верхний попробуйте закрыть парой e2e-тестов. Откройте на хабре статью про управление процессами, про тестирование в других компаниях, подумайте, как это можно применить.

Выходите за рамки и содействуйте качеству на всех уровнях. May the quality be with you.