Право сказать «нет» релизу: когда QA блокирует выпуск и как это делать без войны

Пятница, 17:40. Релиз запланирован на 19:00, маркетинг уже прогрел пуш, менеджер в чате пишет «ну что, едем?». А ты двадцать минут назад нашёл баг: при определённой последовательности действий пользователь теряет несохранённый прогресс. Не у всех, не всегда, но воспроизводится стабильно. И вот перед тобой выбор, который рано или поздно встаёт перед каждым тестировщиком: сказать «стоп» и стать человеком, который сорвал релиз, или промолчать и стать человеком, который знал.

Хорошая новость: выбор не бинарный. Плохая: чтобы им пользоваться, нужно сначала разобраться, что именно у QA за право и откуда оно берётся.

QA — не шлагбаум

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

Майкл Болтон ещё в 2010-м написал известный текст Testers: Get Out of the Quality Assurance Business. Его мысль: тестировщик не «обеспечивает» качество и не владеет им, он даёт людям, принимающим решения, информацию о состоянии продукта и рисках. Звучит как понижение в должности, но на деле это освобождает. Если QA — шлагбаум, то каждый баг в проде — его вина, а каждый сорванный релиз — его самодурство. Если QA — источник информации о риске, то его работа — сделать эту информацию ясной, своевременной и невозможной для игнорирования.

Но «не шлагбаум» не значит «наблюдатель». Право сказать «я не рекомендую выпускать» у тестировщика есть всегда, и пользоваться им — не бунт, а прямая часть работы. Разница только в формулировке: не «я запрещаю», а «вот риск, вот что я рекомендую, решать вам — но решение должно быть осознанным».

Когда «нет» оправдано

Не каждый баг — повод останавливать релиз. Если блокировать всё подряд, через месяц твоё «стоп» перестанут слышать: это история про мальчика, который кричал «волки». Поэтому полезно заранее знать, какие риски действительно тянут на блокер.

Почти везде это:

Потеря данных или денег. Пропадает прогресс, сохранения, покупки; списывается не та сумма; двойное списание.
Безопасность и персональные данные. Утечка токенов, доступ к чужим данным, PII в логах.
Необратимость. Миграция базы, которую нельзя откатить; изменение формата сохранений; рассылка, которую не отзовёшь. Всё, что после релиза не исправить хотфиксом.
Сломан основной сценарий для заметной доли пользователей. Не открывается приложение, не проходит регистрация, не работает оплата.
Юридические и платформенные риски. Нарушение политик стора, отсутствие обязательного согласия, некорректные возрастные рейтинги.
Нет пути назад. Отката нет, фича-флага нет, а мобильный релиз после ревью быстро не заменишь.

А вот что обычно не тянет на блокер: косметика, редкий кейс с понятным обходным путём, баг в фиче, которую можно выключить флагом, проблема на устройстве из 0,3% аудитории. Это повод для тикета и пометки в релизных заметках, но не для «стоп».

Удобная мысленная проверка — четыре вопроса. Насколько вероятно, что пользователь на это наткнётся? Насколько больно, если наткнётся? Можно ли это быстро откатить или выключить? Заметим ли мы это сами, или узнаем из отзывов? Если ответы «вероятно, больно, нельзя, не заметим» — это блокер, даже если баг выглядит невинно. Если «редко, неприятно, можно выключить, заметим» — почти наверняка нет.

Как сказать «нет», чтобы тебя услышали

Самая частая ошибка — сообщить риск эмоцией. «Там всё сломано», «я бы такое не выпускал», «ну вы как хотите». Такие фразы легко отмахнуть, потому что в них нет ничего, с чем можно работать.

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

«Нашёл баг: если свернуть приложение во время автосохранения, прогресс уровня теряется. Воспроизводится стабильно на Android и iOS, шаги в тикете. Влияние: пользователь теряет до 15 минут игры, вероятны гневные отзывы в первые дни после пуша. Варианты: 1) отложить релиз до понедельника, фикс оценили в полдня; 2) выпустить сейчас на 5% аудитории и докатить после фикса; 3) выпустить на всех и выкатить хотфикс. Рекомендую второй вариант. Решение за вами, нужно до 18:30».

Посмотри, что здесь происходит. Тестировщик не «запрещает», но и не прячет риск. Он дал всё, чтобы решение было осознанным: что сломано, насколько это больно, какие есть пути и что он сам считает правильным. И поставил срок — потому что «подумаем» за час до релиза означает «выпустим как есть».

Ещё пара правил:

Сообщай сразу. Риск, о котором сказали за час до релиза, звучит как саботаж. Риск, о котором сказали за два дня, звучит как работа. Если видишь проблему во вторник — говори во вторник, даже если не уверен на сто процентов.
Пиши, а не говори. Устное «я же говорил» не существует. Сообщение в релизном треде или тикете — существует.
Говори с тем, кто решает. Не в личку разработчику, не в общий чат «на всякий случай», а владельцу релиза. Иначе риск растворится между людьми, каждый из которых решит, что кто-то другой уже передал.

Между «да» и «нет»

Спор «выпускаем или нет» почти всегда ложный. Между этими полюсами есть целый набор вариантов, и предложить их — лучшее, что тестировщик может сделать для команды:

Поэтапная раскатка. И в Google Play, и в App Store можно выпустить версию на часть аудитории. В App Store фазированный релиз идёт 7 дней, его можно поставить на паузу. Баг увидят 1-5% пользователей, а не все.
Выключить фичу флагом. Если проблемная часть за фича-флагом, релиз можно выпустить с ней выключенной.
Выпустить без проблемной фичи. Иногда её можно просто убрать из сборки или отложить в следующий релиз.
Выпустить с планом хотфикса. Если риск терпимый, но неприятный, — заранее договориться: кто чинит, когда хотфикс, кто следит за метриками.
Сдвинуть на день. Часто «релиз в пятницу вечером» — просто привычка, а не жёсткий дедлайн. Понедельник утром нередко устраивает всех, когда об этом спрашивают вслух.
Предупредить пользователей и поддержку. Известная проблема в релизных заметках и готовый ответ для саппорта сильно снижают ущерб.

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

Если выпустили вопреки

Бывает, что ты всё сказал правильно, а решение — выпускать. Это нормально, и это не поражение. У принимающего решение могли быть причины, которых ты не видишь.

Что делать в этот момент:

Убедиться, что решение осознанное. Одна фраза в треде: «Правильно понимаю: выпускаем с известным багом X, риск принят, хотфикс планируем на понедельник?» Это не попытка поймать на слове, а фиксация. Через неделю все будут помнить по-разному.
Disagree and commit. У Amazon это один из принципов лидерства: спорь, пока решение не принято, а после — работай на его успех. Значит: подготовить мониторинг, проверить план отката, держать связь с поддержкой.
Никогда не говорить «я же говорил». Даже если баг выстрелил ровно так, как ты предсказывал. Твоё сообщение и так есть в треде, его увидят на постмортеме. Злорадство разрушает доверие быстрее любого бага.

Есть и крайний случай, о котором полезно знать. В 1986 году инженеры Morton Thiokol, включая Роджера Божоли, накануне запуска «Челленджера» рекомендовали не запускать шаттл: при таком холоде уплотнительные кольца ускорителей могли не удержать газы. Менеджмент рекомендацию пересмотрел, запуск состоялся, семь человек погибли. Это далеко от мобильной игры, но урок тот же: если риск касается безопасности людей, их денег или данных, а возражение тонет — его нужно поднимать выше и фиксировать письменно. Тихое согласие в таких случаях — не командная игра.

Сделай «нет» правилом, а не мнением

Лучший способ избежать споров в пятницу вечером — договориться заранее, в спокойный вторник. Когда критерии описаны до релиза, «нет» перестаёт быть твоим личным мнением и становится правилом, о котором все знали.

Что можно договорить заранее:

Критерии выхода. Что должно быть выполнено для релиза: пройден смок, нет открытых блокеров и критичных багов, проверены платёжные сценарии, есть план отката.
Определение severity. Что такое блокер, что критичный, что минорный — на примерах вашего продукта. Тогда спор «это блокер или нет» превращается в сверку с таблицей.
Кто принимает решение. Один человек, а не «команда». Чтобы ты знал, кому писать, и чтобы риск нельзя было размазать.
Бюджет ошибок. В SRE есть идея error budget policy: пока надёжность в норме, команда выпускает смелее; когда бюджет исчерпан — релизы фич замораживаются до стабилизации. Это хороший образец того, как превратить «мне кажется рискованно» в объективное правило.

Калибровка: когда «нет» стало привычкой

И честная обратная сторона. Если ты блокируешь каждый второй релиз, проблема может быть не в команде, а в калибровке. Стоит спросить себя: сколько из моих «стоп» за последние полгода оказались оправданными? Что случилось с релизами, которые выпустили вопреки мне?

Если почти всегда ничего страшного — возможно, твой порог риска выше, чем нужно продукту. Это не плохо само по себе, но это повод поговорить с лидом на 1-1: какой уровень риска для нас приемлем? Тестировщик, который точно знает, когда стоит говорить «нет», ценнее того, кто говорит его часто.

Чек-лист: перед тем как сказать «нет»

Проверь, что риск реальный: баг воспроизводится, шаги записаны, влияние понятно.
Прогони четыре вопроса: вероятность, ущерб, обратимость, обнаружимость.
Найди, кто принимает решение о релизе, и пиши ему, а не в общий чат.
Сформулируй: факт, влияние, варианты, рекомендация, срок решения.
Предложи варианты между «да» и «нет»: поэтапная раскатка, флаг, выпуск без фичи, хотфикс, сдвиг.
Пиши письменно, в релизном треде или тикете.
Если решили выпускать — зафиксируй принятый риск одной фразой и помоги выпустить безопасно.
Не говори «я же говорил». Никогда.
В спокойное время договорись о критериях выхода и уровнях severity.
Раз в полгода сверь свои «стоп» с тем, что произошло на самом деле.

Право сказать «нет» релизу — это не власть, а ответственность за то, чтобы риск был виден. Тестировщик, который делает его видимым вовремя, ясно и с вариантами, редко оказывается тем, кто «сорвал релиз». Гораздо чаще — тем, кто его спас.