Знакома ситуация: вы нашли критический баг на стейдже, но релиз-лид/PM уже сказал «Пускаем, дедлайн». Давление, внутренний конфликт, вопрос «кто будет крайним?». Разбираем: как принимать решение, как аргументировать позицию и как профессионально обезопасить себя. 🔑Главное правило: QA не «разрешает» релиз Тестировщик не блокирует и не одобряет релиз единолично.

Наша зона ответственности: ✅Оценить качество продукта ✅Выявить и задокументировать риски ✅Дать обоснованную рекомендацию Зона ответственности бизнеса (PM, Release Lead, PO): ✅Принять финальное решение с учётом рисков, дедлайнов и ресурсов                                                ➡️Сценарий: найден крит на стейдже. Алгоритм действий⬇️

🟡Шаг 1. Зафиксируйте баг фактами, а не эмоциями Без этого любой спор останется «мнением»: Шаги воспроизведения + окружение (OS, browser, app version) Скриншоты, видео и тд Частота воспроизведения (100% / 50% / 1 раз из 10) Есть ли workaround (обходной путь)? 🟡Шаг 2. Оцените реальный бизнес-риск Здесь многие спотыкаются.

⬇️Используйте два ключевых фильтра:  ✅Фильтр А: Ядро продукта или Edge-case? Чтобы быстро оценить масштаб бедствия, сравните свой баг с двумя типами сценариев:

🔴Ядро (Core) — это то, ради чего пользователь вообще открыл ваше приложение. ▫️Суть: Основной сценарий, который нужен 80–100% аудитории. ▫️Примеры: Не работает оплата, не грузится главная страница, падает логин, не добавляется товар в корзину. ▫️Последствия: 🔴Прямая потеря денег, массовый отток, репутационный удар. Вердикт: Если баг здесь — это почти всегда блокер для релиза.

🟡Edge-case (Граничный случай) - это редкие ситуации, в которые попадает малая часть пользователей. ▫️Суть: Специфические условия, редкие устройства или неочевидные пути в приложении. Затрагивает <1–5% аудитории. ▫️Примеры: Не применяется редкий фильтр в настройках, баг при вводе эмодзи в комментарий, верстка «поехала» на экране с нестандартным разрешением. ▫️Последствия: 🟡Локальные жалобы, единичные тикеты в поддержку, минимальное влияние на бизнес-метрики. Вердикт: Часто можно релизить с известным багом, если есть план фикса.

🧠_Быстрый тест: «Сможет ли обычный пользователь выполнить главную задачу в продукте с этим багом?»_ Нет → Ядро → 🔴Высокий риск Да, но с дискомфортом → Серая зона → 🟡Средний риск Да, если он очень специфический пользователь → Edge → 🟡Низкий риск

Шаг 3. Идите к лиду не со «стоп», а с вариантами ❌ «Мы не можем релизить, тут крит!» ✅«Обнаружен дефект ___. Риск: высокий. Влияние: (конкретика). Варианты: Сдвинуть релиз на 2 часа на фикс, Выпустить с известным багом + план мониторинга и хотфикса, Отключить фичу флагом для уязвимых сегментов. Рекомендация QA: вариант 1, так как риск потери конверсии > стоимости задержки. Решение за вами.»

📎Чек-лист: как обезопасить себя как QA Фиксируйте, кто и на каком основании принял решение: «Релиз одобрен (Имя/Роль) с принятием риска по багу #1234. План мониторинга: [ссылка]. Ответственные за пост-релиз: @dev @support.»

Сохраняйте артефакты. Отчёты, переписку, тест-кейсы. После инцидента это ваша страховка.

Помните о границах. Вы не блокируете релиз единолично. Вы подсвечиваете риски.

⚠️Релиз состоялся вопреки вашему мнению. Что делать?

Не говорите «я же говорил». Говорите: «Инцидент подтвердил оценку риска из #тикет. Переходим к плану mitigation.» Запустите подготовленный мониторинг. Вы уже должны знать, где смотреть логи, какие метрики отслеживать.

Участвуйте в разборе как эксперт. Фокус на процессе: почему баг не отловился раньше? Как улучшить покрытие/окружение/чек-листы?

#инфо