Процессы pull request

Updated Jul 2026

Почему PR важны для QA

QA-инженеры и создают, и ревьюируют pull request. Хорошо написанный PR сливается быстрее, ревьюируется тщательнее и вызывает меньше проблем интеграции. Плохо написанный PR отнимает время у всех, получает формальное одобрение и привносит проблемы, которые можно было бы поймать при ревью.

Написание хороших описаний PR

Описание PR должно отвечать на три вопроса: что изменилось, почему изменилось и как проверить.

Шаблон

## What
Added retry logic to flaky payment API tests and split the checkout
suite into two shards for parallel execution.

## Why
Payment tests were failing 15% of the time due to third-party API
timeouts. The checkout suite was the bottleneck in our pipeline (12 min).

## How to verify
- Run `npm run test:payment` -- should see retry on timeout, 0% flake rate
- Check pipeline -- checkout stage should complete in ~6 min (down from 12)

## Test evidence
- 10 consecutive green runs on this branch: [link to CI]
- Flake rate before: 15% | after: <1%

## Related
- Fixes #234 (flaky payment tests)
- Part of Epic: Pipeline Speed (#100)

Что делает этот шаблон эффективным

• «What» говорит ревьюеру, на чём сосредоточиться. Без этого ему придётся восстанавливать ваш замысел из диффа.
• «Why» объясняет мотивацию. «Снижение процента нестабильности с 15% до <1%» гораздо убедительнее, чем «исправлены тесты».
• «How to verify» даёт ревьюеру конкретные шаги. Ему не нужно гадать, как проверить изменение.
• «Test evidence» показывает, что вы уже проверили изменение. Это укрепляет доверие и ускоряет одобрение.
• «Related» ссылается на задачи, эпики и обсуждения для контекста.

Размер PR: чем меньше, тем лучше

Крупные PR ревьюируются плохо. Исследования показывают, что качество ревью значительно падает после 400 строк изменений. Для тестового кода порог ещё ниже, потому что логику тестов сложнее отследить, чем логику приложения.

Как сохранять PR маленькими

• Разделяйте по функциональным областям: вместо одного PR с 20 тестовыми файлами отправьте отдельные PR для тестов авторизации, оформления заказа и оплаты.
• Разделяйте по типу изменений: один PR для новых тестов, другой для рефакторинга существующих, третий для инфраструктурных изменений.
• Разделяйте по уровням: один PR для page objects, другой для тестовых спецификаций, использующих их.
• Используйте стек PR: PR 1 добавляет базовую инфраструктуру. PR 2 (основанный на PR 1) добавляет первый набор тестов. PR 3 добавляет ещё тесты.

Когда большие PR неизбежны

Иногда приходится отправлять большой PR (например, при миграции тестового фреймворка). В таких случаях:

• Добавьте подробное описание PR, объясняющее объём
• Используйте комментарии к PR, чтобы провести ревьюера по изменениям
• Разбейте ревью на сессии: «Пожалуйста, сначала проверьте page-objects/, затем specs/»
• Рассмотрите проведение встречи-разбора для PR более 1000 строк

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

Хорошие сообщения коммитов делают историю доступной для поиска и результаты bisect осмысленными.

Формат

type(scope): short description

Longer description if needed. Explain why, not what.
The code diff shows what changed; the message should explain why.

Refs: #234

Типы для QA-работы

Плохие vs хорошие сообщения коммитов

# Bad
fix tests
update
WIP
changes
asdfasdf

# Good
fix(checkout): stabilize payment test by increasing API timeout to 30s
test(login): add 2FA verification tests for SMS and authenticator app
ci: split browser tests into 4 shards to reduce pipeline from 20m to 6m
refactor(page-objects): extract checkout form into reusable component

Процесс ревью PR

Как автор PR

1. Сначала проведите саморевью: прочитайте свой дифф перед запросом ревью. Вы часто сами заметите проблемы.
2. Добавьте контекстные комментарии: если участок кода неочевиден, добавьте комментарий к PR, объясняя его, до того как ревьюер спросит.
3. Отмечайте черновые PR как черновики: если PR не готов к ревью, используйте функцию draft PR в GitHub, чтобы ревьюеры не тратили время.
4. Оперативно реагируйте на обратную связь: PR, который лежит днями после ревью, тормозит команду.
5. Не принимайте обратную связь на свой счёт: ревьюер критикует код, а не вас.

Как ревьюер PR

1. Поймите контекст: прочитайте описание PR и связанные задачи перед просмотром кода.
2. Проверьте тесты: содержательны ли утверждения? Детерминистичен ли тест? Выполняет ли он за собой очистку?
3. Проверьте граничные случаи: что происходит при пустом вводе, null-значениях, сетевых ошибках?
4. Ищите захардкоженные значения: настраиваемы ли URL, таймауты и учётные данные?
5. Проверьте именование: можно ли понять, что делает каждый тест, только по его названию?

Автоматизация процесса PR

Обязательные проверки

Настройте репозиторий так, чтобы перед слиянием требовалось прохождение определённых проверок:

Branch protection rules for main:
  ✅ Require pull request reviews (1 approval minimum)
  ✅ Require status checks (unit-tests, integration-tests, lint)
  ✅ Require branches to be up to date before merging
  ✅ Require conversation resolution before merging

Автоматическое назначение

Используйте CODEOWNERS для автоматического назначения ревьюеров на основе изменённых файлов:

# .github/CODEOWNERS
tests/             @qa-team
playwright.config.ts @qa-team
.github/workflows/ @qa-team @devops-team

Шаблоны PR

Создайте .github/pull_request_template.md для стандартизации описаний PR:

## What
<!-- What changed? -->

## Why
<!-- Why was this change needed? -->

## How to verify
<!-- Steps to verify the change works -->

## Checklist
- [ ] Tests pass locally
- [ ] No hardcoded credentials or URLs
- [ ] Test names are descriptive
- [ ] PR is reasonably sized (< 400 lines)

Практическое упражнение

1. Напишите описание PR для недавнего изменения тестов, используя шаблон выше
2. Проверьте один из ваших старых PR. Улучшил бы его шаблон?
3. Настройте файл CODEOWNERS для ваших тестовых директорий
4. Создайте шаблон PR в .github/pull_request_template.md
5. Потренируйтесь в предоставлении обратной связи на тестовый PR коллеги, используя чеклист ревьюера
6. Найдите PR в вашем репозитории объёмом более 500 строк. Как его можно было бы разбить?