Опишите ситуацию, когда релиз шёл с известными дефектами. Как вы участвовали в решении go/no-go?

Релиз с известными дефектами и решение go/no-go

Ситуация, когда релиз выходит «с долгом» — не исключение, а регулярная реальность. Ключевая компетенция QA senior-уровня — не заблокировать всё, а дать команде и бизнесу структурированную информацию для осознанного решения.

Конкретный кейс

Перед выпуском major обновления checkout-модуля тестирование выявило 14 дефектов. Из них 2 Critical, 5 High, 7 Medium/Low. Исправить всё за оставшиеся 2 дня было нереально, а задержка стоила бизнесу запланированный маркетинговый запуск.

Мой вклад в go/no-go

Я подготовил risk-отчёт для синхронизации (участвовали: PM, tech lead, CTO, я):

• Critical #1: сбой при оплате через Apple Pay на iOS 16 — затрагивает ~15% транзакций. Воспроизводится стабильно. Без фикса — прямые потери выручки.
• Critical #2: некорректный расчёт скидки при стековании двух промокодов — редкий сценарий (0.3% заказов), финансовый риск ~$200 в день.
• High: 5 дефектов связаны с edge cases в адресной форме (неподдерживаемые символы, очень длинные адреса) — workaround существует.

К каждому прилагал: severity, частоту воспроизведения, бизнес-влияние, наличие workaround, оценку времени на фикс.

Итог решения

Команда решила: релиз идёт с патчем Critical #1 (разработчик взял hotfix за ночь), Critical #2 митигируется отключением стековки промокодов feature flag'ом до следующего релиза, High — в backlog первым приоритетом. Я согласился с этим решением, зафиксировал все known issues в release notes и настроил alert в Sentry на критические сценарии для мониторинга post-release.

Принципы участия QA в go/no-go

• QA не блокирует релиз — QA предоставляет данные. Решение принимает бизнес.
• Severity должна отражать реальное влияние, а не «теоретически плохо».
• Для каждого нефиксированного дефекта — mitigation plan или acceptance decision.
• После релиза — повышенный мониторинг (Sentry, Grafana, поддержка на дежурстве).

Подводные камни

• QA занимает позицию «не выпускать с багами» без учёта бизнес-контекста — это не партнёрство, а блокировка.
• Размытые severity без количественного влияния — PM не может принять решение по «это серьёзно».
• Нет фиксации known issues в release notes — саппорт и пользователи не предупреждены.
• Mitigation через feature flag не тестируется отдельно — флаг может сломать другое.
• Отсутствие мониторинга после релиза — известный риск реализуется, а команда узнаёт от пользователей.
• Давление на QA «подписать» релиз без времени на тестирование — нужно явно фиксировать, что тестирование неполное.
• go/no-go без представителя бизнеса — технические решения принимаются без контекста приоритетов.

• Говорить «нельзя релизить с багами» без оценки impact.
• Замолчать known issue ради срока.
• Не иметь rollback или communication plan.

• Оценивает risk and impact.
• Формулирует release recommendation.
• Учитывает пользователей, поддержку и rollback.