Во всём виноват тестировщик

Упал прод? QA пропустил.

Нашли баг у клиента? Почему тестирование не поймало?

Очень удобная модель: качество можно вынести в отдельную функцию.

А потом вокруг неё появляются команды качества, клиентского опыта, аудита, reliability, quality gates и ещё несколько контуров контроля.

Каждый из них сам по себе может быть полезен.

Но есть побочный эффект: чем больше людей формально отвечают за качество, тем проще самой продуктовой команде перестать считать качество своей ответственностью.

И дальше начинается организационная магия.

У команды есть основной backlog.

Потом появляется отдельный backlog качества.

Потом задачи от клиентского опыта.

Потом аудит. Потом эксплуатация. Потом ещё чей-то список обязательных улучшений.

Каждая функция смотрит на свой кусок и вполне искренне говорит: «Команда почему-то ничего не делает».

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

В итоге получается парадокс: чем больше вокруг команды механизмов управления качеством, тем меньше целостного понимания качества остаётся внутри самой команды.

И рядом часто появляются красивые лозунги.

Например: Zero Bugs Policy. Звучит отлично.

Но я бы сразу спросил: что именно считается багом, какой severity, считаем ли редкие ошибки, деградации, UX-проблемы?

Потому что KPI «ноль багов» иногда приводит не к нулю проблем, а к нулю зарегистрированных проблем.

Это уже не управление качеством. Это управление цифрой.

Как тогда живут команды без отдельного QA?

Нормально живут.

Потому что качество — это не роль и не последний этап перед production.

Это свойство того, как команда принимает решения, проектирует систему, выпускает изменения и смотрит на результат после релиза.

Если неправильно поняли проблему — можно идеально протестировать не то решение.

Если плохо спроектировали систему — тестирование не сделает её надёжной.

Если релизный процесс хрупкий — количество тест-кейсов не спасёт.

Если после выкладки никто не смотрит на реальное поведение клиента — можно вообще не заметить деградацию.

Поэтому качество нельзя вынести из команды целиком.

Можно дать ей экспертизу. Можно дать инструменты. Можно построить автоматизацию, observability, quality gates и независимые проверки.

Но ответственность за качество результата должна оставаться у команды, которая этот результат создаёт.

И только после этого имеет смысл говорить о метриках:

Defect Leakage. Change Failure Rate. MTTR. Availability и Error Rate ключевых сценариев. Повторные инциденты. Динамика критичных дефектов.

То есть: изменили → измерили → увидели проблему → улучшили → снова измерили.

Поэтому мне всё меньше нравится вопрос: «Кто у вас отвечает за качество?»

И всё больше нравится другой: «Как команда сама понимает, что её продукт стал качественнее?»

Если для ответа ей нужно собрать пять разных отчётов из пяти разных функций, значит, систему качества мы уже построили слишком далеко от самой команды.

А если команда не может сама ответить, стало качество её продукта лучше или хуже, значит, качество уже слишком далеко от неё уехало.