Работа с Git, GitHub, GitLab и GitLab CI

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

Живёте ли вы в репозитории наравне с разработчиками. Для тестировщика это не только коммиты в свои автотесты, но и понимание, как прогон встроен в пайплайн, где лежат отчёты и почему сборка красная.

Как отвечать

Разделите ответ на повседневный Git и на CI.

Git: ветка на задачу, понятные сообщения коммитов, синхронизация с основной веткой (git switch -c, git fetch, git rebase или git merge), разбор конфликтов руками, изменения уезжают через merge request с ревью. Скажите, лежит код автотестов в репозитории приложения или в соседнем, и почему у вас именно так.

CI: пайплайн описан в .gitlab-ci.yml, задачи разложены по стадиям, выполняет их раннер.

stages: [test]
smoke:
  stage: test
  script:
    - pytest -m smoke --junitxml=report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

Дальше важные для тестировщика детали: на merge request гоняется быстрый набор, полный регресс уходит в ночной запуск по расписанию; отчёт сохраняется артефактом, иначе падение придётся разбирать по сырым логам; доступы и токены лежат в переменных проекта, а не в файле пайплайна; нестабильные тесты помечаются и чинятся, а не глушатся повторным запуском.

Отдельный плюс, если расскажете, как готовите данные и окружение внутри прогона и как чистите их после.

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

Путают Git и хостинг. Git это система контроля версий, работающая локально, а GitHub и GitLab это площадки поверх неё; фраза про хранение кода в облаке сразу понижает уровень кандидата.

Второе: вешают весь регресс на каждый merge request. Пайплайн растягивается на час, разработчики перестают его ждать и начинают вливать ветки с красной сборкой.

Третье: кладут логин и пароль от тестового стенда прямо в файл пайплайна. Секрет попадает в историю репозитория, и одним коммитом его оттуда уже не убрать, нужна ротация.