Какие задачи выполняли в GitLab?

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

Работали ли вы с GitLab как с частью процесса тестирования или только нажимали кнопку «Approve». Интервьюеру важно, понимаете ли вы, как автотесты попадают в пайплайн и как команда видит их результат. Следом спрашивают: «Как устроен ваш пайплайн?» или «Что делали с нестабильными тестами?»

Как отвечать

Разложите опыт от простого к сложному и назовите то, что делали сами:

• Merge Request: ревью кода автотестов, обсуждение изменений, разрешение конфликтов, связь MR с задачей;
• .gitlab-ci.yml: стадии и джобы для запуска тестов, образ Docker с нужной версией Python или Java, условия запуска через rules (старые only и except уже не развиваются);
• отчёты: artifacts:reports:junit, чтобы упавшие тесты показывались прямо в MR, Allure-отчёт как артефакт или на GitLab Pages;
• ускорение: parallel для деления набора тестов на части, needs, чтобы не ждать всю предыдущую стадию, кеш зависимостей;
• расписание: pipeline schedules для ночного полного регресса, а на каждый MR только быстрый смоук;
• окружения и секреты: маскированные CI/CD-переменные для логинов и токенов тестовых стендов вместо паролей в репозитории;
• задачи: Issues и доски, если баг-трекинг жил в GitLab, а не в отдельной системе.

Хороший ответ звучит так: «Я написал джобу, которая на каждый MR гоняет API-тесты на pytest в Docker, результаты видны в MR через JUnit-отчёт, а полный UI-регресс идёт ночью по расписанию». Цифры приводите свои: сколько тестов, сколько длился прогон до и после распараллеливания. Если CI настраивали DevOps-инженеры, скажите честно и расскажите, что вы в нём меняли или читали.

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

Путают Git и GitLab: рассказывают про commit и rebase, хотя вопрос про платформу, CI и процесс.

Лечат нестабильные тесты через retry и считают вопрос закрытым. Повтор прячет проблему, а интервьюеру интересно, как вы находили причину.

Приносят выдуманные метрики вроде «время выхода фич сократилось на 30%». Тестировщик редко может такое посчитать, и вопрос «как считали» ставит в тупик.