Кто отвечает за выкатывание релизов
Что проверяют
Понимаете ли вы процесс выкладки целиком и своё место в нём. Интервьюер хочет услышать, где заканчивается ответственность QA и что вы делаете до выкладки и после неё. Следом часто спрашивают, кто принимает решение «выкатываем или нет» и что делать, если после релиза посыпались ошибки.
Как отвечать
Ответ зависит от устройства команды, и это нормально сказать прямо. Три распространённых варианта:
- команда сама выкатывает свой сервис: кнопку в пайплайне GitLab CI, Jenkins или GitHub Actions нажимает разработчик или дежурный. DevOps и платформенная команда отвечают за сам конвейер, а не за каждый релиз;
- выделенный релиз-менеджер: собирает релизную ветку, согласует состав, ведёт календарь. Типично для больших продуктов и мобильных приложений;
- полная автоматизация: изменение после мержа и прохождения проверок уходит в прод без ручного шага.
Роль QA во всех трёх случаях похожая:
- регресс и quality gate: упавшие автотесты в пайплайне блокируют выкладку, критичные сценарии проходят ручным регрессом на стейдже;
- участие в go/no-go: QA докладывает, что проверено, какие баги известны и насколько они серьёзны. Решает владелец релиза с учётом этого отчёта;
- смоук после выкладки: короткая проверка ключевых сценариев на проде, особенно при канареечном выпуске или включении фича-флага на часть пользователей;
- критерии отката: заранее понятно, при каком росте ошибок релиз откатывают.
Для мобильных приложений добавьте поэтапную раскатку в Google Play и App Store, когда версия сначала уходит небольшой доле пользователей.
Где спотыкаются
Говорят, что за релиз отвечает QA, раз он «дал добро». Это делает тестировщика виноватым за каждый баг на проде и не отражает реальный процесс.
Считают релиз завершённым после деплоя. Смоук на проде и наблюдение за метриками в первые часы входят в работу.
Не знают, как в их команде откатывали релиз. Хотя бы общую схему, редеплой прошлой версии или выключение флага, стоит назвать.