Есть ли quality gate между тестовыми контурами

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

Есть ли в вашем процессе формальные критерии перехода сборки между средами, или релиз двигается по ощущению «вроде всё проверили». Следом спрашивают, кто принимает решение и что происходит, когда гейт красный, а релиз нужен срочно.

Как отвечать

Вопрос про ваш опыт, поэтому говорите о своём проекте: какие контуры (dev, test, stage или препрод, прод) и что проверяется на каждой границе. Опорная схема:

• dev → test: сборка собралась, юнит-тесты и интеграционные тесты зелёные, статический анализ прошёл. В SonarQube это его Quality Gate, который смотрит на новый код: покрытие, дублирование, новые замечания;
• test → stage: пройдены автотесты API и UI (Playwright, Selenium, Postman с Newman), по задачам релиза нет открытых блокеров и критических дефектов;
• stage → прод: регресс по критическим сценариям, smoke на окружении, близком к боевому, при необходимости нагрузочный прогон относительно базовой линии и подпись ответственного.

Хорошо назвать техническую реализацию: этапы пайплайна в GitLab CI или Jenkins, ручное подтверждение деплоя в защищённое окружение, отчёт Allure как основание для решения. В терминах ISTQB это критерии входа и выхода.

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

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

Называют гейтом «тестировщик посмотрел и дал добро». Без записанных критериев это не гейт, а мнение одного человека.

Ставят порог по общему проценту покрытия и считают, что качество под контролем. Процент ничего не говорит о том, покрыты ли критичные сценарии.

Не имеют правил на исключения. Хотфикс уходит в обход гейта без записи о рисках, а нестабильные (flaky) тесты красят гейт так часто, что красный цвет перестают замечать.