Это один из самых токсичных вопросов в IT. Потому что почти всегда его задают не для анализа проблемы, а для поиска виноватого.

Чья же вина, когда баг доехал до прода?

Хотя баг на проде зачастую говорит не о провале конкретного человека, а о сбое в системе принятия решений.

Бывают конечно и очевидные случаи. Тестировщик пропустил критичный сценарий. Разработчик сломал старую логику. Аналитик не описал важное поведение. Но если смотреть глубже, баг редко появляется из воздуха и почти никогда не проходит весь цикл незамеченным только из-за одного человека.

Прод - это последняя точка длинной цепочки: * требования, * декомпозиция, * разработка, * код-ревью, * тестирование, * коммуникация, * сроки, * приоритеты, * релизное давление.

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

А после релиза приходит тот самый бизнес: «Почему QA пропустил?» Хотя QA в этот момент часто был последней ниточкой-фильтром при удержании проблемы на ранних стадиях, а не виновником ситуации.

Но мы и не будем полностью снимать ответственность с тестирования. Это тоже будет странно. Если человек видел риск и понимал последствия, а задачу катнули дальше - это уже часть ответственности.

Ведь работа QA не в том, чтобы гарантировать отсутствие багов. Это невозможно. Еще раз. Его задача - дать команде информацию о минимизации рисков до релиза.

Поэтому вопрос «кто виноват?» обычно бесполезен. Намного полезнее другой: Почему система позволила этому багу попасть на прод? Почему команда системы оказалась слаба перед багом?

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

Голосуйте реакциями: 💜 - Система так отреагировала 🍾 - QA конечно 😱 - Никто не виноват, случай