Недавно мы выпускали крупное обновление. В ходе подготовки команда обнаружила более 200 дефектов, устраняла их, проводила функциональные проверки и регрессию. Но после запуска возникли проблемы с производительностью и отдельными сценариями. Релиз откатили.

Для меня здесь два важных вопроса. И оба — не только к QA.

1. Почему вообще возникло столько дефектов?

200 найденных багов — большая работа тестировщиков. Но сама цифра не должна быть поводом для гордости или поиска виноватых.

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

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

Зрелый процесс не просто хорошо находит ошибки. Он сокращает вероятность их появления.

И это уже совместная работа продукта, разработки и QA: понятные требования, ранняя обратная связь, ревью решений, проверки на разных уровнях.

2. Что для нас означает «готов к релизу»?

Для QA — пройдены необходимые проверки. Для разработки — реализована функциональность. Для бизнеса — пришло время выпускать обновление.

Но готовность к релизу — это не сумма галочек. Это осознанное принятие рисков.

Ещё до запуска важно понимать: → Какие риски остаются и кто принимает решение их принять? → Насколько проверки отражают реальные условия эксплуатации? → Какие метрики покажут, что релиз пошёл не по плану? → Когда останавливаем раскатку или откатываемся? → Можем ли быстро и безопасно вернуться к стабильному состоянию?

Последний пункт особенно важен. Обратная совместимость, миграции данных, feature flags, постепенная раскатка и мониторинг — не дополнения «на всякий случай», а часть стратегии релиза.

Не нужно героически чинить в продакшене то, что можно безопасно откатить.

Hotfix иногда необходим. Но если откат безопасен, чаще разумнее сначала восстановить стабильность для пользователей, а затем спокойно разбирать причины и готовить исправление.

И после инцидента фраза «надо было лучше тестировать» не должна заменять анализ. Надо разобраться, почему дефекты возникли, почему риски не обнаружили раньше и что в системе нужно изменить.

Для меня зрелость инженерной команды — не в отсутствии ошибок. А в том, насколько хорошо она предупреждает их появление, управляет рисками и сохраняет контроль, когда что-то идёт не по плану.