Ответ.

Организация ручного тестирования на этапе релиза — это комплекс мер для быстрого и эффективного поиска дефектов в подготовленной к выкату версии продукта, с фокусом на наиболее критичных и часто используемых функциях.

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

Проблема: Ограниченное время на тестирование перед релизом не позволяет проверить всё, кроме того нарастает человеческий фактор — усталость, спешка, стресс. Часто критические баги всплывают только после выката, подрывая репутацию продукта и создавая хаос в команде.

Решение:

Совместно с бизнесом, аналитиками, dev оценить критичные и бизнес-значимые сценарии.
Сформировать релизный чек-лист с так называемыми "режущими" сценариями — те, которые чаще всего используются или рискованны.
Провести финальное smoke- и sanity-тестирование вручную: проверить запуск системы, процесс логина, оформления заказа, оплату и т. д.
Ясно разграничить зоны ответственности: кто отвечает за тестовые данные, кто — за отчеты о найденных дефектах, кто — за коммуникацию с dev.

Ключевые особенности:

Приоритизация багов: находить и эскалировать критичное в первую очередь.
Использование кратких, быстро исполняемых тест-кейсов и чек-листов.
Оперативная коммуникация с командой разработки для быстрой фиксации.

Вопросы с подвохом.

Можно ли "перестраховаться" и вручную проверить вообще всё приложение перед релизом?

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

Стоит ли перед релизом открывать "мелкие" баги, чтобы команда о них знала заранее?

Нет, в релизном режиме стоит эскалировать только критические и блокирующие дефекты, а менее значимые оформить как known issues и взять в работу после выката.

Обязательно ли вручную писать детальные тест-кейсы на этап релиза?

Нет, часто проще и быстрее работать с чек-листами или мини-скриптами снятыми с тест-кейсов, что позволяет оперативно пройтись по релевантным сценариям.

Типовые ошибки и анти-паттерны

Откладывание тестирования до последних часов — из-за чего всё делается в спешке, с потерей качества.
Проверка редко используемых или маловажных сценариев в ущерб ключевым.
Отсутствие финального smoke/sanity непосредственно перед релизом.

Пример из жизни

Негативный кейс

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

Плюсы:

Высокая скорость проверки.

Минусы:

Критичный баг не замечен.
Риски стрессовой середины ночи, упущенная коммуникация с dev.

Позитивный кейс

Перед релизом фокус берётся только на критичные сценарии (логин, оплата, сохранение заказа, интеграцию с партнёрами). Итоги прогоняются по чек-листу, баги эскалируются мгновенно.