Где запускаются тесты: локально или на сервере

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

Как у вас устроен путь автотеста от написания до регулярного прогона и умеете ли вы объяснить, почему тест прошёл на ноутбуке и упал в пайплайне. Следом обычно спрашивают, какой CI вы использовали, сколько длится прогон и что делаете с нестабильными тестами.

Как отвечать

Правильный ответ почти всегда «и там и там», но с разными задачами:

• локально: пишете и отлаживаете тест, запускаете один класс или тег, смотрите браузер в headed-режиме, ставите брейкпоинты. Гонять весь регресс на ноутбуке долго и бессмысленно;
• в CI: GitLab CI, Jenkins, GitHub Actions или TeamCity запускают smoke на каждый merge request, полный регресс по расписанию или перед релизом. Окружение одинаковое для всех, результат не зависит от того, что установлено у конкретного человека;
• инфраструктура: браузеры в Docker, Selenium Grid или облачные фермы вроде BrowserStack, параллелизация через --shard в Playwright или потоки в TestNG и JUnit, зависимые сервисы через Testcontainers;
• отчётность: Allure или HTML-отчёт Playwright с трейсами и скриншотами, ссылка на отчёт в merge request, уведомление в чат при падении.

Хорошо, если опишете и стенды: тесты гоняются против dev или stage окружения, а не против продакшена, и данные для них готовятся заранее через API или фикстуры.

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

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

Говорят «запускаем только локально перед релизом». Значит, автотесты зависят от одного человека и не ловят регрессию на каждом изменении.

Не могут объяснить расхождения между локальным и серверным прогоном. Типичные причины: headless-режим и другое разрешение экрана, другая временная зона, общий стенд с чужими данными, параллельные тесты, которые мешают друг другу.

Лечат нестабильность только ретраями. retries в конфиге прячет проблему, такие тесты нужно чинить или выносить в карантин с заведённой задачей.