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