Быстро воспроизведите проблему и зафиксируйте ожидаемое поведение, фактический результат и ущерб пользователю. С разработчиком сверяйтесь с требованиями, а не спорьте о слове «баг». Если трактовка расходится, подключите владельца продукта и ответственного за релиз. Предложите перенос, исключение проблемного изменения или проверенное исправление. Решение о выпуске и принятом риске должно быть явным; неподтверждённый фикс нельзя считать безопасным.
Что делать, если за два часа до релиза найден критический баг, а разработчик считает его фичей?
Как подтвердить дефект, обсудить риск с разработчиком и ответственными за релиз и зафиксировать решение, когда до выпуска остаётся два часа.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
За два часа до релиза важно сократить неопределённость и сделать риск видимым. Спор о том, назвать поведение багом или фичей, сам по себе не помогает решить, безопасно ли выпускать продукт.
Сначала подтвердите наблюдение: воспроизведите проблему на релизной сборке, запишите шаги, данные, окружение и фактический результат. Укажите, какое поведение ожидалось и на чём основано ожидание: требование, критерий приёмки, согласованный сценарий или ранее работавшая функция. Отдельно опишите последствия: какие пользователи затронуты, теряются ли данные, блокируется ли ключевой сценарий и есть ли обходной путь.
Обсудите эти факты с разработчиком. Возможно, он знает о согласованном изменении поведения; возможно, обнаружен неучтённый сценарий. Если требования неоднозначны, трактовку должен подтвердить владелец продукта или другой ответственный за требования, а не один из участников спора.
Параллельно сообщите о риске ответственному за релиз и действуйте по принятому процессу. Предложите реалистичные варианты:
- Перенести выпуск до устранения и проверки проблемы.
- Исключить проблемное изменение или отключить функцию, если такой способ уже предусмотрен и проверен.
- Выполнить ограниченное исправление, затем повторить проблемный сценарий и необходимые смежные проверки.
- Если выпуск всё же согласован, явно зафиксировать остаточный риск, ответственного за его принятие, наблюдение после релиза и условия отката.
Рекомендация QA при подтверждённом критическом риске — не выпускать затронутую функциональность без приемлемого решения. При этом право остановки релиза зависит от договорённостей команды: не стоит изображать единоличное решение, если такого полномочия нет.
Итог обсуждения сохраните в задаче или релизном решении. Обещание разработчика быстро исправить код не заменяет проверку исправления, а отсутствие явного возражения не означает принятия риска.