До релиза один день, а тестирования осталось на три. Как поступите?
Короткий ответ
- Сразу сообщить о проблеме, а не молчать до дедлайна
- Приоритизация по рискам: критичные пути и новые изменения
- Смоук и регресс затронутых областей — обязательный минимум
- Автотесты и помощь команды для ускорения
- Честный отчёт: что проверено, что нет, какие риски
- Решение о релизе принимает бизнес на основе рисков
- После релиза — дотестировать и разобрать причину ситуации
Задача QA — не успеть всё, а проверить самое рискованное и дать бизнесу честную картину для решения о релизе.
Как сказать вслух
пример ответаПервое — немедленно эскалирую: говорю менеджеру, что объём не помещается в срок, молчать тут хуже всего. Дальше приоритизирую по рискам: критичные бизнес-сценарии, всё новое и изменённое в релизе, интеграции. Запускаю автоматизированный регресс, прошу помощи у команды, если возможно. На выходе даю честную картину: вот что проверено, вот что нет, вот риски по непроверенному. Решение о выпуске принимает бизнес, но на основе моей информации. После релиза дотестирую остальное и предложу разобрать, почему так вышло.
Подробный ответ
Основной ответ
Вопрос проверяет риск-ориентированное мышление и коммуникацию под давлением. Правильная последовательность: немедленная прозрачность — менеджер и команда узнают о нехватке времени сразу, с оценкой объёма; приоритизация по рискам — в первую очередь критичные пользовательские пути (деньги, логин, основной флоу), новая и изменённая функциональность этого релиза, области с историей дефектов; обязательный минимум — смоук плюс регресс затронутых областей; ускорители — автоматизированный регресс, подключение разработчиков и аналитиков к проверкам по чек-листу, возможность отрезать часть функциональности от релиза фиче-флагом. Ключевой пункт — отчёт о рисках: что проверено, что нет и чем это грозит; решение «выпускать или переносить» принимает владелец продукта, а QA даёт ему основания. Запасные варианты тоже стоит озвучить: перенос релиза, выпуск частью функциональности, усиленный мониторинг и готовность к откату после выпуска. После релиза — дотестирование пропущенного и ретроспектива: почему тестирование оказалось зажато — поздняя передача, недооценка, раздутый скоуп.
Ключевые моменты
- Эскалация сразу. Молчание до дедлайна превращает проблему планирования в инцидент на проде.
- Риски, не алфавит. Порядок проверок определяется стоимостью отказа, а не удобством или привычкой.
- QA информирует, бизнес решает. Тестировщик не блокирует релиз единолично — он даёт честную картину рисков.
- Ретроспектива после. Повторяющийся цейтнот — симптом процесса: поздние сборки, недооценка, отсутствие автоматизации.
Практический контекст
Почти гарантированный поведенческий вопрос на любом QA-интервью. Проверяют две вещи: не станет ли кандидат молча геройствовать ночами и умеет ли приоритизировать по рискам. Сильный ответ опирается на реальный случай с конкретикой: что выбрали проверять, что отложили, чем кончилось. Ответ «успею всё, посижу ночью» — красный флаг для интервьюера.
Частые ошибки
- Обещают «успеть всё» за счёт ночной работы вместо приоритизации
- Принимают решение о релизе единолично, вместо того чтобы дать бизнесу картину рисков
- Не упоминают пострелизные шаги: дотестирование, мониторинг, разбор причин цейтнота