В чем разница между DoD и DoR?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Разница между DoD и DoR в Agile и DevOps
DoD (Definition of Done) и DoR (Definition of Ready) — это два ключевых концепта в Agile методиках, особенно в Scrum, которые служат для повышения качества продукта и эффективности процесса разработки. Они представляют собой четкие, согласованные критерии, но применяются на разных этапах жизненного цикла задачи.
Определение и сущность
Definition of Done (DoD) — это формальный список критериев, которые должны быть выполнены, чтобы рабочая единица (например, задача, пользовательская история, фича) считалась завершенной и могла быть поставлена в Production. DoD — это контракт на выход, гарантирующий, что результат соответствует стандартам качества, готов к использованию и не создает технического долга. Это соглашение между всей командой (разработчиками, тестировщиками, аналитиками) и часто включает критерии, относящиеся к DevOps и автоматизации.
Пример содержимого DoD для задачи в проекте с автоматизированным тестированием:
Definition_of_Done:
- Код написан и соответствует стандартам кодирования.
- Код проверен через peer review (например, Pull Request).
- Все новые или измененные функции покрыты автоматизированными unit-тестами.
- Автоматизированные интеграционные тесты пройдены успешно.
- Регрессионное тестирование выполнено (автоматизированное или ручное).
- Документация (API, пользовательская) обновлена.
- Код успешно развернут на staging-окружении.
- Произведен smoke test на staging.
- Нет открытых критических или блокирующих багов, связанных с задачей.
- Performance-метрики (если применимо) соответствуют требованиям.
Definition of Ready (DoR) — это список критериев, которые должны быть удовлетворены перед тем, как рабочая единица (чаще всего пользовательская история) будет принята разработчиками в текущий спринт для реализации. DoR — это контракт на вход, гарантирующий, что задача четко определена, имеет все необходимые детали для начала работы и ее выполнение не будет тормозиться из-за недостатка информации. Это соглашение между бизнес-стороной (владельцем продукта, аналитиками) и технической командой.
Пример содержимого DoR для пользовательской истории:
Definition_of_Ready:
- История имеет четкий, не технический заголовок и описание.
- Критерии приемки (Acceptance Criteria) четко сформулированы и покрывают основные сценарии.
- Приоритет и бизнес-ценность определены.
- Все необходимые дизайны, mockups или спецификации API готовы и доступны.
- Зависимости от других задач или систем идентифицированы и разрешены.
- Оценка сложности (например, в story points) проведена и согласована командой.
- История разбита на технически выполнимые размеры (не является эпиком).
Ключевые различия в контексте QA Automation
| Критерий | Definition of Ready (DoR) | Definition of Done (DoD) |
|---|---|---|
| Момент применения | Перед взятием задачи в спринт (планирование). | После завершения всех работ по задаче (закрытие). |
| Основная цель | Гарантировать, что задача понятна и подготовлена для эффективной разработки. | Гарантировать, что результат полностью завершен и соответствует качеству для поставки. |
| Кто устанавливает и проверяет | Владелец продукта (Product Owner), бизнес-аналитики, и команда на планировании. | Вся команда (Dev, QA, DevOps), проверяет каждый разработчик/тестировщик при завершении своей части. |
| Фокус на деталях | Бизнес- и функциональные требования (что нужно сделать). | Технические и процессные стандарты (как это должно быть сделано и проверено). |
| Влияние на QA Automation | Критерии приемки (AC) в DoR формируют основу для тест-кейсов, особенно для автоматизации UI или API-тестов. Четкий DoR позволяет QA заранее начать подготовку тестов. | DoD включает прямые требования к автоматизации: написание/адаптация тестов, проход CI/CD пайплайна, тестирование на staging. Автоматизация является частью "завершенности". |
| Риски при несоблюдении | Задача берется в спринт без четкого плана, приводит к задержкам, непониманию, некорректной реализации и, как следствие, к плохо автоматизируемым или тестируемым функциям. | Задача считается завершенной без должного качества, приводит к скрытым багам, неавтоматизированным сценариям, сбоям в Production и накоплению технического долга, который сложно автоматизировать позже. |
Практическая интеграция в процесс
Для QA Automation Engineer понимание и участие в формировании обоих определений критически важно.
-
На этапе DoR: QA должен убедиться, что критерии приемки (Acceptance Criteria) написаны тестируемым образом (например, в формате "Given-When-Then"), что они покрывают граничные условия и что нет противоречий, которые сделают автоматизацию невозможной. Это предотвращает ситуацию, когда автоматизатор получает задачу, которую нельзя корректно покрыть тестами.
-
На этапе DoD: QA активно обеспечивает выполнение пунктов, связанных с тестированием. Например:
* **Автоматизированные тесты написаны и проходят.** Это часто является отдельным пунктом в DoD.
* **Тестовое покрытие (Code Coverage) для unit-тестов соответствует стандарту проекта** (например, >80%).
* **Интеграция тестов в CI/CD:** успешный проход пайплайна, включающего stages для запуска автоматизированных тестов (unit, integration, API, e2e), является обязательным условием DoD.
* **Регрессионное тестирование выполнено:** либо через автоматизированный регрессионный suite, либо подтверждено ручным тестированием, если автоматизация не покрывает 100%.
Синтез
Таким образом, DoR и DoD — это два взаимодополняющих, но противоположно направленных соглашения. DoR фокусируется на правильном начале работы, обеспечивая четкость и отсутствие препятствий, что напрямую влияет на возможность эффективного планирования автоматизации тестов. DoD фокусируется на правильном окончании работы, устанавливая высокий барьер качества, который невозможен без интеграции автоматизированного тестирования в процесс разработки и поставки. Игнорирование DoR приводит к хаосу на входе, игнорирование DoD — к рискам на выходе. Успешная QA Automation требует активного участия в определении и соблюдении обоих.