Настраивали ли пайплайны
Что проверяют
Умеете ли вы встраивать тесты в поставку, а не запускать их со своего ноутбука. Вопрос отделяет тестировщика, который отдаёт автотесты «куда-то в CI», от инженера, который сам правит конфиг, разбирает падения и отвечает за то, чтобы пайплайн не врал.
Как отвечать
Описать конкретный пайплайн, который трогали, по стадиям:
- триггеры: пулреквест, мерж в основную ветку, ночной регресс по расписанию;
- стадии: сборка, статический анализ, юнит-тесты, интеграционные на поднятых зависимостях (контейнеры с базой и заглушками внешних сервисов), сквозные на развёрнутом стенде;
- данные: как создаются тестовые данные, чистятся ли после прогона, как разводятся параллельные ветки на одном стенде;
- отчётность: единый отчёт с шагами, скриншоты, логи и трассировки при падении, уведомление в чат команды;
- гейт: что именно блокирует мерж, кто разбирает красное и за какой срок.
Дальше самое ценное: как ускоряли прогон (параллельность, разделение дымового набора и полного регресса) и что делали с нестабильными тестами. Карантин и починка, а не молчаливое отключение.
Где спотыкаются
Называют инструмент вместо опыта. «Работал с готовым пайплайном» без ответа на то, кто писал конфиг и что делали при падении, звучит как «видел ссылку на сборку в чате».
Второе: приносят выдуманные цифры вроде «время тестирования сократилось на 40%, дефектов на проде стало меньше на 30%». Спросят базу замера и состав регресса, и цифры рассыпаются.
Третье: не различают быструю обратную связь и полный прогон. Если на пулреквест повешен весь регресс на два часа, разработчики начинают мержить не дожидаясь результата, и гейт становится украшением.