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