Как часто запускаются автотесты
Что проверяют
Понимаете ли вы, что частота запуска зависит от уровня тестов и их скорости, а не выбирается одна на всё. Следом обычно спрашивают, сколько длится пайплайн на мерж-реквест и что вы делаете с нестабильными тестами.
Как отвечать
Стройте ответ по триггерам, от быстрых проверок к тяжёлым:
- на каждый пуш: юнит-тесты и линтеры. Счёт на минуты, иначе разработчики перестают ждать результата;
- на мерж-реквест: смоук и API-тесты по затронутой области. Красный результат блокирует мерж, поэтому набор должен укладываться примерно в четверть часа;
- после деплоя на стенд: e2e-сценарии через UI на Playwright или Selenium;
- по расписанию: полный регресс ночью через pipeline schedules в GitLab или
cron-триггер в Jenkins. Результат должен кто-то разбирать утром, иначе ночной прогон бесполезен; - перед релизом: полный регресс на сборке-кандидате;
- после релиза: короткий смоук на проде, только читающие проверки.
Чтобы тяжёлые наборы запускать чаще, их ускоряют: параллелят через pytest-xdist (-n auto), шардируют Playwright (--shard=1/4), гоняют браузеры в Selenoid или Selenium Grid. Отчёт собирают в Allure, где видна история каждого теста.
Отдельно скажите про нестабильные тесты. Их выносят в карантин с тикетом на починку, а автоматические повторы (retries в Playwright) включают осторожно: они прячут настоящие гонки в приложении.
Если в вашем проекте всё было проще, например регресс раз в спринт запускали вручную из Jenkins, так и скажите и объясните, почему этого хватало или что вы бы изменили.
Где спотыкаются
Отвечают «раз в сутки» без разбивки по уровням. Интервьюер слышит, что тесты живут отдельно от разработки.
Вешают полный UI-регресс на каждый коммит. Пайплайн растягивается на час, и команда начинает мержить в обход.
Лечат нестабильность повторами. Тест проходит с третьей попытки, отчёт зелёный, а баг с гонкой уезжает в прод.