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

Очень часто вижу, как в компаниях после релиза, где вылез критичный баг, начинается «охота на ведьм». Виноват тестировщик — не нашёл, не проверил, недоглядел.
Но на практике баги попадают в прод по трём основным причинам:

1. Отсутствие чётких требований. Если спецификаций нет или они постоянно меняются, тестировщик проверяет «на глаз», а не по чётким критериям. Итог — разные ожидания у QA и у заказчика.
2. Сжатые сроки. Классика: дедлайн вчера, тестирование в два раза короче запланированного, при этом проверок меньше, автоматизация не прогоняется полностью.
3. Сложность воспроизведения. Есть баги, которые проявляются только при определённых нагрузках, конфигурациях или после долгой работы приложения. Их реально трудно найти до релиза.

Поэтому важно не искать виноватого, а разбирать причины:

- Улучшить требования.
- Планировать время на тестирование.
- Инвестировать в автоматизацию и нагрузочные проверки.

А ещё полезно после каждого релиза проводить post-mortem — разбор инцидента без обвинений. Это помогает команде учиться, а не бояться.

#qa #testing

Подпишись👉 @testlab_qa