Git для QA-инженеров

Зачем QA-инженерам Git #

Каждый профессиональный проект автоматизации использует контроль версий. Git — отраслевой стандарт. Как QA automation engineer, вы будете:

• Хранить тест-код в репозиториях рядом с кодом приложения
• Создавать ветки для новых наборов тестов
• Отправлять pull requests для code review
• Разрешать конфликты слияния при одновременной работе нескольких человек
• Использовать историю Git для понимания, когда и почему менялись тесты
• Интегрироваться с CI/CD-пайплайнами, срабатывающими по событиям Git

Основные команды Git #

Начальная настройка #

# Настройка идентификации
git config --global user.name "Ваше Имя"
git config --global user.email "ваш.email@company.com"

# Клонирование репозитория
git clone https://github.com/company/test-automation.git
cd test-automation

# Проверка текущего состояния
git status

Команды ежедневного рабочего процесса #

# Получить последние изменения с удалённого репозитория
git pull origin main

# Создать новую ветку для работы
git checkout -b feature/add-login-tests

# Посмотреть изменённые файлы
git status
git diff

# Добавить конкретные файлы в staging
git add tests/login.spec.ts
git add tests/fixtures/users.json

# Коммит с описательным сообщением
git commit -m "Добавить набор тестов страницы логина с позитивными и негативными сценариями"

# Push ветки на удалённый репозиторий
git push origin feature/add-login-tests

Просмотр истории #

# Просмотр истории коммитов
git log --oneline -20

# Что изменилось в конкретном коммите
git show abc1234

# Кто последний раз менял каждую строку файла
git blame tests/login.spec.ts

# Найти, когда тест был добавлен или изменён
git log --follow tests/checkout.spec.ts

Стратегия ветвления для тест-кода #

Соглашения по именованию веток #

Используйте ясные, описательные имена:

feature/add-checkout-tests      # Новый набор тестов
feature/POM-login-page          # Новый page object
fix/flaky-search-test           # Исправление нестабильного теста
refactor/base-test-class        # Рефакторинг существующего кода
chore/update-playwright-version # Обновление зависимостей

Процесс работы с feature-ветками #

main ─────────────────────────────────────────
       \                              /
        feature/add-login-tests ─────

1. Создать ветку от main
2. Внести изменения и закоммитить
3. Push на удалённый репозиторий и открыть pull request
4. Получить code review от коллег
5. CI автоматически запускает тесты
6. Слияние после утверждения

Поддержание ветки в актуальном состоянии #

# Пока вы работаете, в main могут появиться новые коммиты
git checkout main
git pull origin main
git checkout feature/add-login-tests
git rebase main

# Или merge main в вашу ветку
git merge main

Процесс Pull Request #

Создание хорошего PR для тест-кода #

Хороший pull request включает:

Заголовок: Чёткое описание добавленных/изменённых тестов

Добавить E2E-тесты страницы логина с edge cases

Описание:

## Что сделано
- Добавлены 12 тест-кейсов для страницы логина
- Покрывает позитивный логин, невалидные данные, блокировку аккаунта, SSO

## Покрытие тестами
- Happy path: валидный вход по email/паролю
- Негативные: неверный пароль (3 попытки → блокировка)
- Edge cases: SQL injection в поле email, XSS в пароле
- SSO: OAuth-потоки Google и GitHub

## Добавленные Page Objects
- LoginPage: login(), forgotPassword(), socialLogin()
- DashboardPage: verifyWelcome(), logout()

## Как запустить
npm run test:login

Чеклист code review для тест-кода #

При ревью PR с тестами проверяйте:

• Тесты имеют ясные, описательные имена
• Нет захардкоженных данных (используются фикстуры или фабрики)
• Корректное использование page objects (без сырых селекторов в тестах)
• Ассерты конкретные и осмысленные
• Тесты независимы (нет зависимости от порядка)
• Очистка обработана (тестовые данные, состояние браузера)
• Нет ненужных wait или sleep

Разрешение конфликтов слияния #

Конфликты возникают, когда два человека редактируют один файл. В автоматизации это часто происходит в:

• Общих page objects
• Файлах конфигурации тестов
• Файлах тестовых данных

Разрешение конфликта #

# Когда видите конфликт после merge или rebase
# Git помечает конфликтующие секции:

<<<<<<< HEAD (ваши изменения)
async login(email, password) {
  await this.page.fill('#email-v2', email);
}
=======
async login(email, password) {
  await this.page.fill('[data-testid="email"]', email);
}
>>>>>>> main (входящие изменения)

# Разрешите, выбрав правильную версию или объединив обе
async login(email, password) {
  await this.page.fill('[data-testid="email"]', email);
}

# Затем добавьте и закоммитьте
git add tests/pages/login.page.ts
git commit -m "Разрешить конфликт: использовать data-testid селектор для email"

.gitignore для тестовых проектов #

Правильный .gitignore предотвращает попадание ненужных файлов в репозиторий:

# Результаты и отчёты тестов
test-results/
playwright-report/
allure-results/
allure-report/
coverage/

# Скриншоты и видео из запусков
screenshots/
videos/
traces/

# Зависимости
node_modules/
.venv/

# Файлы IDE
.vscode/
.idea/
*.swp

# Файлы окружения с секретами
.env
.env.local

# Файлы ОС
.DS_Store
Thumbs.db

# Билд-артефакты
dist/
build/

Git Hooks для качества тестов #

Git hooks автоматически запускают скрипты при определённых событиях Git:

Pre-Commit Hook #

Запуск линтинга перед каждым коммитом:

#!/bin/sh
# .git/hooks/pre-commit
npx eslint tests/ --ext .ts,.js
if [ $? -ne 0 ]; then
  echo "Линтинг не прошёл. Исправьте проблемы перед коммитом."
  exit 1
fi

Pre-Push Hook #

Запуск тестов перед push:

#!/bin/sh
# .git/hooks/pre-push
npx playwright test --grep @smoke
if [ $? -ne 0 ]; then
  echo "Smoke-тесты упали. Исправьте перед push."
  exit 1
fi

Продвинутый Git для QA #

Сохранение незавершённой работы через stash #

# Временно сохранить незакоммиченные изменения
git stash save "WIP: тесты checkout"

# Переключиться на другую ветку для срочного исправления
git checkout fix/flaky-login-test

# Вернуться и восстановить работу
git checkout feature/checkout-tests
git stash pop

Cherry-pick исправления #

# Применить конкретный коммит из другой ветки
git cherry-pick abc1234

Bisect для поиска сломавшего теста коммита #

# Найти коммит, внёсший баг
git bisect start
git bisect bad           # Текущий коммит сломан
git bisect good abc1234  # Этот старый коммит работал

# Git переключает на промежуточный коммит — запустите тест
npx playwright test tests/login.spec.ts

# Сообщите Git результат
git bisect good  # или git bisect bad

# Повторяйте, пока Git не найдёт виновный коммит
git bisect reset  # По завершении

Лучшие практики совместной работы #

Рекомендации по сообщениям коммитов #

# Хорошие сообщения
git commit -m "Добавить E2E-тесты checkout для гостевого и зарегистрированного пользователя"
git commit -m "Исправить нестабильный тест поиска: увеличить таймаут ожидания ответа API"
git commit -m "Рефакторинг LoginPage: вынести методы заполнения форм в BaseFormPage"

# Плохие сообщения
git commit -m "поправить тесты"
git commit -m "обновление"
git commit -m "WIP"

Атомарные коммиты #

Каждый коммит должен быть логической единицей:

• Один коммит на функцию или исправление
• Тесты должны проходить после каждого коммита
• Не смешивать несвязанные изменения

Упражнение: Практика рабочего процесса Git #

Отработайте следующий процесс:

1. Склонируйте тестовый репозиторий (или создайте новый)
2. Создайте ветку feature/add-search-tests
3. Добавьте файл tests/search.spec.ts с двумя тест-кейсами
4. Закоммитьте с описательным сообщением
5. Создайте вторую ветку feature/add-filter-tests от main
6. Измените один и тот же конфигурационный файл в обеих ветках
7. Слейте обе ветки и разрешите конфликты
8. Просмотрите историю через git log --graph --oneline

Ключевые выводы #

• Используйте feature-ветки для всех изменений тест-кода
• Пишите описательные сообщения коммитов, объясняя что и почему
• Всегда забирайте последние изменения перед началом новой работы
• Разрешайте конфликты слияния, понимая оба набора изменений
• Используйте .gitignore для исключения результатов и отчётов из репозитория
• Git hooks автоматизируют проверки качества перед коммитом и push