Какие сложности возникают при запуске автотестов на стороне заказчика и как их решать
Что проверяют
Был ли у вас опыт, когда тесты уезжают из вашего CI в чужой контур, и умеете ли вы делать их переносимыми. Следом часто спрашивают: «Как отличить падение из-за бага от падения из-за стенда заказчика?»
Как отвечать
Разложите сложности по типам и к каждой дайте решение:
- закрытый контур: нет выхода в интернет, зависимости из Maven Central, PyPI или npm не скачать, браузеры для Playwright или Selenium тоже. Решение: зеркало через Nexus или Artifactory, заранее собранный Docker-образ с тестами и браузерами;
- другое окружение: другие версии браузеров, ОС и JDK, свой CI (Jenkins, GitLab CI, TeamCity) и свои раннеры. Решение: вся конфигурация через переменные окружения и профили (
BASE_URL, учётки из секретов CI), никаких захардкоженных адресов; - данные: на стенде нельзя свободно создавать и удалять записи, а копия прода закрыта из-за персональных данных. Решение: тесты сами создают данные через API и чистят за собой, а не опираются на «того самого пользователя с id 42»;
- общий нестабильный стенд: им пользуются другие команды, он медленнее вашего. Решение: health-check перед прогоном, явные ожидания вместо
sleep, разумные таймауты, быстрый smoke-набор по тегу; - доступы и безопасность: VPN, двухфакторная авторизация, капча, запрет на Docker. Решение: заранее согласовать с безопасниками тестовые учётки без 2FA и отключённую капчу;
- отчётность: заказчик должен понимать, что упало. Решение: Allure-отчёт со скриншотами, логами и шагами плюс короткая инструкция по запуску.
Подкрепите ответ своим случаем: что не взлетело на первом запуске и сколько времени ушло на перенос.
Где спотыкаются
Отвечают общими словами про «нехватку квалифицированного персонала» и «обучение команды». Интервьюер ждёт технических причин: сеть, зависимости, данные, конфигурация.
Предлагают прогнать тесты у себя и прислать отчёт. Смысл в том, чтобы тесты воспроизводимо работали именно в контуре заказчика.
Не разделяют падения по причинам. Если каждую красную сборку разбирают вручную, заказчик быстро перестаёт доверять автотестам, поэтому нужны метки причин («баг», «окружение», «нестабильный тест») и перезапуск упавших.