Definition of Done

Updated Jul 2026

Почему Definition of Done критически важен

Definition of Done (DoD) -- это общее соглашение команды о том, что значит «сделано». Без явных тестовых критериев в DoD «сделано» по умолчанию означает «разработчик думает, что это работает». Это приводит к тому, что истории отмечаются завершёнными без адекватного тестирования, баги просачиваются в продакшен, и возникают споры о том, действительно ли что-то «сделано».

Хорошо определённый DoD -- самый значимый процессный артефакт, который QA-инженер может продвигать.

Сильный Definition of Done

Вот DoD для команды с дисциплиной качества:

• Код рецензирован и одобрен минимум одним коллегой
• Юнит-тесты написаны и проходят (покрытие не уменьшается)
• Интеграционные тесты написаны для новых API-эндпоинтов
• Браузерные тесты написаны для новой пользовательской функциональности
• Ручное исследовательское тестирование выполнено
• Нет открытых дефектов критической или высокой серьёзности
• Доказательства тестирования привязаны к истории (URL CI-прогона, скриншоты)
• Базовые проверки доступности выполнены (клавиатурная навигация, метки для скринридера)
• Документация обновлена при изменении поведения
• Развёрнуто на staging и пройдено дымовое тестирование

Анатомия каждого пункта DoD

Код-ревью

Код-ревью -- первый контроль качества. Оно выявляет логические ошибки, проблемы безопасности и проблемы дизайна до начала тестирования.

Перспектива QA на код-ревью: QA-инженеры должны участвовать в ревью, особенно для:

• Тестового кода (является ли он детерминированным, изолированным, хорошо именованным?)
• Кода приложения, влияющего на тестируемость (есть ли атрибуты data-testid, контракты API?)
• Конфигурационных изменений (переменные окружения, фиче-флаги)

Покрытие юнит-тестами

Юнит-тесты проверяют отдельные функции и методы в изоляции. Это самые быстрые тесты, и они должны покрывать все значимые логические ветки.

Что означает «покрытие не уменьшается» на практике:

• Новый код должен иметь юнит-тесты
• Удаление кода может уменьшить покрытие (это приемлемо)
• Рефакторинг должен сохранять или улучшать покрытие
• Конкретный порог (например, 80%) менее важен, чем тренд

Интеграционные тесты

Интеграционные тесты проверяют, что компоненты работают вместе: API-эндпоинты, запросы к базе данных, взаимодействия сервисов.

Когда история добавляет или изменяет API-эндпоинт, интеграционные тесты должны проверить:

• Happy path: корректный запрос возвращает корректный ответ
• Пути ошибок: невалидный ввод возвращает соответствующие коды ошибок
• Граничные случаи: граничные значения, пустые коллекции, большие данные

Браузерные тесты

Браузерные тесты проверяют сквозной пользовательский опыт в реальном браузере. Они должны покрывать основные пользовательские потоки, добавленные или изменённые историей.

Не каждая история нуждается в браузерных тестах. Чисто бэкенд-изменение, модифицирующее запрос к базе данных, не требует нового браузерного теста (хотя существующие браузерные тесты должны по-прежнему проходить).

Исследовательское тестирование

Исследовательское тестирование -- это ручное, креативное тестирование, которое автоматизированные тесты не могут заменить. Оно обнаруживает проблемы, о которых никто не подумал при написании тестов.

Чек-лист исследовательского тестирования:

• Попробуйте неожиданные вводы (эмодзи, очень длинные строки, специальные символы)
• Тестируйте при медленном сетевом соединении
• Тестируйте с разными пользовательскими ролями и правами
• Тестируйте функцию на мобильных вьюпортах
• Попытайтесь сломать функцию, используя её способами, не описанными в спецификации

Доказательства тестирования

«Доверяй, но проверяй» применимо и к тестированию. Дайте ссылку на CI-прогон, показывающий прохождение тестов, включите скриншоты ручного тестирования и укажите конкретные тестовые файлы.

Примеры доказательств:

• URL CI-прогона: https://github.com/org/repo/actions/runs/12345
• Скриншот: screenshot-checkout-mobile.png
• Ссылка на тестовый файл: tests/checkout/payment.spec.ts

Нет открытых критических или высокосерьёзных дефектов

История не завершена, если у неё есть известные критические или высокосерьёзные баги. Они должны быть исправлены в рамках истории, а не перенесены в другой спринт.

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

Доступность

Доступность -- не «приятное дополнение», а юридическое требование во многих юрисдикциях и стандарт качества.

Минимальные проверки доступности:

• Клавиатурная навигация: можно ли добраться до каждого интерактивного элемента клавишей Tab?
• Метки для скринридера: имеют ли кнопки и поля ввода осмысленные aria-labels?
• Контрастность: читаем ли текст на фоне?
• Индикаторы фокуса: видно ли, где находится фокус клавиатуры?

Внедрение DoD

Шаг 1: Составьте черновик вместе с командой

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

Шаг 2: Начните с малого и развивайте

Если у вашей команды сейчас нет DoD, не вводите чек-лист из 15 пунктов за одну ночь. Начните с 5 пунктов, которые команда может выполнять, а затем добавляйте новые по мере формирования привычки.

Стартовый DoD (минимально жизнеспособное качество):

• Код рецензирован минимум одним коллегой
• Все существующие тесты проходят
• Нет критических дефектов для этой истории
• Развёрнуто в staging-окружение

Зрелый DoD (целевое состояние): Полный список из 10 пунктов выше.

Шаг 3: Сделайте его видимым

DoD должен быть:

• Размещён в Slack-канале команды или вики
• Упоминаться на обзорах спринта («Давайте проверим DoD для этой истории»)
• Распечатан на стене (для команд в одном офисе)
• Частью рабочего процесса Jira (обязательные поля или чек-листы)

Шаг 4: Применяйте без жёсткости

DoD должен соблюдаться последовательно, но исключения случаются. Когда команда согласовывает пропуск пункта DoD для конкретной истории, задокументируйте причину. Если исключения становятся нормой, DoD слишком амбициозен -- сократите его.

Антипаттерны DoD

Измерение эффективности DoD

Отслеживайте эти метрики, чтобы понять, работает ли ваш DoD:

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

1. Запишите текущий Definition of Done вашей команды. Если его нет, это и есть ответ.
2. Сравните его с «сильным DoD» выше. Какие пункты отсутствуют?
3. Предложите 2-3 дополнения к вашему DoD на следующей ретроспективе.
4. Проведите аудит 5 недавно завершённых историй на соответствие DoD. Были ли все пункты действительно выполнены?
5. Измерьте процент просочившихся дефектов за последние 3 спринта. Предотвращает ли DoD баги?