Некоторые люди считают тестировщиков (QA) ответственными за качество во всём процессе разработки. Этих людей можно понять, ведь в названии профессии Quality Assurance сказано, что они не только отвечают за качество, они его обеспечивают.

Считаю такое мышление вредительским.

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

Здесь не работает любимое менеджерами выражение про коллективную безответственность, которую часто используют, чтобы выбрать козла отпущения. Нельзя взять тестировщика Васю и заставить его отвечать за весь продукт. Особенно, если Вася не умеет читать код, не то что писать его.

Всё может пойти не так на каждом из этапов:

• От аналитика придут непроработанные требования, и работа пойдёт не в том направлении с самого начала;
• Разработчик может не так понять, что от него хотят, а уставший под конец дня менеджер согласится с такой трактовкой;
• Разработчик отрефакторит функциональность по пути и забыть сказать об этом тестировщику (напоминаю, что далеко не все тестировщики умеют читать код);
• Тестировщик на пятый круг проверки одной и той же функциональности забивает на кейс, потому что девять раз до этого он отрабатывал правильно;
• При деплое не запускают новый скрипт, в результате продакшн будет работать неправильно;
• Тестовые данные или окружение не совпадает с продашкном — из разрядка классики.

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

Так в итоге, за что же отвечают тестировщики? Как ни парадоксально, но за качество. А если быть точнее, за повышение уровня качества.

Рассмотрим привычный этап тестирования после разработки и до релиза — тестировщики работают с уже готовой фичей по уже готовым требованиям. Остаётся только шлифовать и полировать, повышать уровень качества. Но бизнес ждать не будет, время и бюджет, все дела. Какова вероятность за сильно ограниченное время увеличить качество с 30% до 90%? А если на этап тестирования придёт качественная версия?

Поэтому так много разговоров идёт о Shift Left подходе, об анализе требований, об автоматизации, о превращении тестировщиков в полноценных инженеров. Но это уже другая история…