Как сказать «нет» релизу

Updated Jul 2026

Самый сложный разговор QA-инженера

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

Речь не о полномочиях. Речь об ответственности, данных и способности донести риски настолько ясно, чтобы лица, принимающие решения, могли делать осознанный выбор.

Когда блокировать релиз

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

Критерии для рекомендации блокировки релиза

Критерии для НЕблокирования релиза

Аргументы на основе рисков vs аргументы на основе полномочий

Разница между эффективной и неэффективной блокировкой релиза сводится к тому, как вы строите аргументацию.

Аргументы на основе полномочий (слабые)

Аргументы на основе полномочий опираются на роль QA-инженера как контролёра:

• «Я QA, и я не подписал это.»
• «Мы ещё не закончили тестирование.»
• «Процесс требует согласования QA.»
• «Я не уверен в этом релизе.»

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

Аргументы на основе рисков (сильные)

Аргументы на основе рисков представляют данные, последствия и альтернативы:

• «Три из пяти платёжных потоков содержат непротестированные пути. Если любой из них даст сбой, клиенты будут списаны без получения заказа. Вот список непротестированных сценариев.»
• «У нас 4 критических бага в процессе оформления заказа. Исходя из наших паттернов трафика, приблизительно 2 000 пользователей в час будут попадать на затронутый участок кода.»
• «Скрипт миграции не тестировался на наборе данных продакшен-масштаба. В нашем тесте на staging с 10% данных продакшена он занял 45 минут и дважды завершился по таймауту. В масштабе продакшена мы можем получить 4+ часа простоя.»

Структура аргумента на основе рисков

1. В ЧЁМ риск?
   "The password reset flow does not validate email format."

2. КОГО это затрагивает?
   "Any user who triggers a password reset -- approximately 500 users/day."

3. КАКОВО влияние?
   "Users enter an invalid email, receive no reset link, and cannot
   access their account. Support ticket volume will increase."

4. НАСКОЛЬКО это вероятно?
   "High. 8% of our users have typos in their email addresses
   based on our registration data."

5. КАКОВА альтернатива?
   "We can either delay by 2 hours for a fix, or ship with the
   known issue and add client-side email validation in a hotfix
   tomorrow."

Представление данных: правильный подход

«Вот 5 критических багов» (эффективно)

При рекомендации блокировки релиза представьте краткую сводку, которую лица, принимающие решения, смогут быстро оценить:

Оценка готовности к релизу -- v2.4.0

Рекомендация: Отложить релиз на 1 день

Открытые критические проблемы (5):

ID	Проблема	Влияние	Затронутые пользователи	ETA исправления
BUG-1201	Оформление заказа не работает для сохранённых карт	Невозможно завершить покупку	~30% покупателей	3 часа
BUG-1204	Письмо-подтверждение заказа не отправляется	Пользователи думают, что заказ не прошёл	Все покупатели	1 час
BUG-1207	Цена отображается как $0.00 для комплектов	Пользователи в замешательстве или эксплуатируют баг	~5% заказов	2 часа
BUG-1210	Таймаут сессии при оформлении теряет корзину	Пользователь должен добавить товары заново	~8% сессий	4 часа
BUG-1215	Промокод применяется дважды в граничном случае	Потеря выручки	~1% заказов со скидкой	2 часа

Протестировано и пройдено: 47 из 52 тестовых сценариев (90,4%)

Риск при выпуске: Примерно 2 400 затронутых транзакций за первые 24 часа на основе текущего трафика.

Риск при задержке: Задержка на 1 день для не срочного по времени релиза. Никакие контрактные или маркетинговые обязательства не затронуты.

«Не готово» (неэффективно)

«Я не думаю, что нам стоит выпускать. Всё ещё есть баги, и не всё протестировано. Меня не устраивает качество.»

Это утверждение не даёт лицам, принимающим решения, ничего для работы. Нет конкретики, нет данных, нет альтернатив. Его отклонят, и QA-инженер потеряет авторитет на будущее.

Паттерны эскалации

Когда эскалировать и кому

Принципы эскалации

• Эскалируйте решение, а не обвинения. «У нас есть разногласия по поводу готовности к релизу, и нужен кто-то с более широким контекстом для принятия решения» — это уместно. «Разработчики пытаются выпустить сломанное ПО» — нет.
• Приходите с данными. Никогда не эскалируйте без пакета доказательств — списка багов, оценки влияния, альтернатив.
• Эскалируйте рано, а не поздно. Поднять вопрос в 14:00 даёт варианты. Поднять его в 23:00, когда деплой уже идёт, — нет.
• Документируйте эскалацию. Отправьте follow-up письмо: «Как обсуждалось, я поднял вопрос о проблемах X, Y и Z. Было принято решение продолжить релиз. Я задокументировал известные проблемы и план митигации в [ссылка].»

Компромисс: условный релиз

На практике большинство решений о релизе не являются бинарными (выпускать / не выпускать). Наиболее распространённый и продуктивный результат — это условный релиз: выпуск с известными проблемами и явным планом митигации.

Элементы соглашения об условном релизе

Release: v2.4.0
Date: March 15, 2025
Status: CONDITIONAL RELEASE

Known Issues Shipping:
1. BUG-1207: Price displays as $0.00 for bundled items
   - Mitigation: Server-side price validation prevents $0 orders
   - Fix ETA: Hotfix within 48 hours
   - Monitoring: Alert on any order with $0 line items

2. BUG-1215: Discount code applied twice in edge case
   - Mitigation: Manual review of discounted orders > 30%
   - Fix ETA: Sprint 25
   - Monitoring: Daily report of orders with > 1 discount application

Conditions for Emergency Rollback:
- More than 50 affected transactions in 1 hour
- Any data integrity issue (double charges, lost orders)
- Any security vulnerability discovered

Monitoring Owner: [QA Engineer Name]
Rollback Owner: [DevOps Engineer Name]
Incident Commander: [Engineering Manager Name]

Почему условные релизы работают

• Они признают, что совершенство не всегда возможно или необходимо
• Они создают ответственность, документируя, кто что знает и кто за что отвечает
• Они удовлетворяют потребности бизнеса (выпустить функцию) при управлении рисками (мониторинг и исправление)
• Они укрепляют доверие, потому что QA воспринимается как прагматичная функция, а не как препятствие

Пост-мортемы: когда вы не заблокировали, а должны были

У каждого QA-инженера бывает такой опыт: у вас были сомнения по поводу релиза, вы недостаточно настояли, и релиз вызвал инцидент в продакшене. Пост-мортем — это место, где вы превращаете эту неудачу в системное улучшение.

Безобвинительный пост-мортем

Безобвинительный пост-мортем фокусируется на системе, которая допустила сбой, а не на людях, принимавших решения:

Пример пост-мортема

Инцидент: 2 400 заказов списаны без отправки письма-подтверждения (v2.4.0, 15-16 марта)

Основная причина: Интеграция с почтовым сервисом тестировалась на mock-сервере, который не воспроизводил лимит запросов продакшена. Под продакшен-нагрузкой почтовый сервис начал троттлить запросы, и 15% писем были молча потеряны.

Почему QA это не обнаружил:

• Mock почтового сервиса в staging-окружении не имеет ограничений по частоте запросов
• Нагрузочное тестирование не включало шаг уведомления по электронной почте
• QA поднял вопрос о тестировании почты, но не имел данных для количественной оценки риска

Действия:

1. Добавить ограничение по частоте запросов в staging mock почты (DevOps, Sprint 26)
2. Включить потоки уведомлений в сценарии нагрузочного тестирования (QA, Sprint 26)
3. Добавить мониторинговый алерт при падении доставляемости писем ниже 95% (DevOps, Sprint 26)
4. Обновить чеклист релиза, включив «поток уведомлений протестирован под нагрузкой» (QA, Sprint 26)

Практические сценарии с примерами диалогов

Сценарий 1: Пятничный релиз

Контекст: Команда хочет выполнить деплой крупной функциональности в пятницу после обеда. Вы нашли два бага средней серьёзности и не завершили регрессионное тестирование.

QA: «Хочу обратить внимание на некоторые проблемы с пятничным деплоем. Я нашёл два бага средней серьёзности в поиске — результаты неправильно сортируются при применении фильтра по дате, а пагинация ломается на последней странице. Также я не завершил регрессию по потоку заказов, потому что тестовое окружение было недоступно вчера.»

PM: «Мы пообещали клиенту эту функцию к понедельнику. Можем выпустить и исправить баги на следующей неделе?»

QA: «Вот что я предлагаю: выпускаем функцию с двумя задокументированными известными багами, так как они затрагивают поиск, а не основной поток заказов. Но я бы хотел 2 часа в понедельник утром, чтобы завершить регрессию по потоку заказов, прежде чем мы объявим о функции клиенту. Риск низкий — код потока заказов не менялся — но я хочу убедиться. Если найдём что-то критическое в понедельник, откатим до того, как клиент это увидит.»

PM: «Подходит. Можешь прислать мне список известных проблем, чтобы я мог проинформировать клиента при необходимости?»

Сценарий 2: Критический баг безопасности

Контекст: Вы обнаруживаете уязвимость безопасности за 30 минут до запланированного релиза.

QA: «Мне нужно срочно эскалировать. Во время финального тестирования я обнаружил, что новый API-эндпоинт для профилей пользователей не требует аутентификации. Любой, у кого есть URL, может получить доступ к данным любого пользователя, включая электронную почту и номер телефона.»

Лид разработки: «Ты уверен? Этот эндпоинт должен быть за auth middleware.»

QA: «Я проверил через curl снаружи VPN, без токена аутентификации, и получил полный ответ с профилем пользователя. У меня есть скриншоты и команда curl. Это риск утечки данных.»

Лид разработки: «Хорошо, нам нужно убрать это из релиза. Сможешь проверить исправление, когда мы добавим проверку аутентификации?»

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

Сценарий 3: Давление пропустить тестирование

Контекст: VP спрашивает, почему QA «задерживает» релиз.

VP: «Мне сообщают, что QA блокирует релиз. У нас заседание совета директоров в четверг, и мне нужно показать эту функцию. В чём задержка?»

QA: «Я понимаю срочность. Вот где мы находимся: 90% функциональности протестировано и готово. Оставшиеся 10% — это платёжный поток, который мы не могли протестировать, потому что песочница платёжной системы была недоступна два дня. Сейчас она работает, и мне нужно ещё 4 часа.»

VP: «Можем выпустить без тестирования оплаты?»

QA: «Можем, но платёжный поток — это область наивысшего риска: любой баг там напрямую влияет на выручку. Я бы рекомендовал подождать 4 часа. В качестве альтернативы мы можем развернуть за feature flag, продемонстрировать функцию на заседании совета директоров, а затем включить её для всех пользователей после завершения тестирования в четверг после обеда.»

VP: «Вариант с feature flag подходит. Давайте так и сделаем.»

Практическое упражнение

1. Напишите оценку готовности к релизу для вашего текущего проекта, используя шаблон выше
2. Определите прошлый релиз, который следовало отложить. Напишите аргумент на основе рисков, который вы бы использовали, если бы могли вернуться в прошлое
3. Подготовьте соглашение об условном релизе для функциональности с 2-3 известными проблемами
4. Потренируйте разговор об эскалации: объединитесь с коллегой и разыграйте сценарий «пятничного релиза»
5. Просмотрите процесс пост-мортемов в вашей команде. Включает ли он вопрос «что QA знал и когда?»? Если нет, предложите его добавить