Что такое code freeze и feature freeze и когда они происходят?

Что проверяют

Представляете ли вы релизный цикл целиком и своё место в нём. За вопросом стоит практическая проверка: понимает ли тестировщик, зачем нужна стабильная версия и почему правка после регресса обесценивает уже проведённые проверки.

Как отвечать

Feature freeze наступает раньше. С этого момента новую функциональность в релиз не берут, команда доводит начатое, чинит дефекты и стабилизирует. Объём релиза становится известен, и QA может планировать регресс и приёмку, а не гоняться за меняющимся набором задач.

Code freeze наступает ближе к выпуску. В релизную ветку не попадает ничего, кроме исправлений, прошедших отдельное согласование: блокеры, критические дефекты, уязвимости. Цель именно в том, чтобы результат регресса оставался действительным к моменту выпуска.

Что стоит добавить сверх определений: заморозка делается веткой, а не устной договорённостью, разработка следующего релиза при этом продолжается в основной ветке. Выход из заморозки описывается критериями: нет открытых блокеров, регресс зелёный, приёмка подписана. В командах с непрерывной поставкой роль заморозки берут на себя фича-флаги, и отдельного стоп-крана может не быть вовсе.

Где спотыкаются

Меняют этапы местами и объявляют, что сначала замораживается код, а потом функциональность. Из такой схемы сразу следует неразрешимое противоречие: непонятно, чем чинить дефекты, найденные в ходе тестирования.

Считают, что тестирование начинается после заморозки. Проверки идут весь цикл, а заморозка нужна для финального регресса, сборки кандидата и приёмки. Команда, которая ждёт заморозки, чтобы начать тестировать, гарантированно опаздывает с релизом.

Не оговаривают процедуру исключений. Кто утверждает правку, обязателен ли повторный прогон затронутой области, кто пересобирает кандидата. Без этого в выпуск улетает однострочное исправление, которое никто не перепроверил, и оно ломает то, что было зелёным.