Критерии приёмки

Критерии приёмки — это важный инструмент бизнес-анализа, который определяет, когда история пользовательского требования считается завершенной с точки зрения пользователя. Они играют ключевую роль в обеспечении того, что разработанный продукт соответствует ожиданиям бизнеса и пользователей. Формат Gherkin (Given / When / Then) широко используется благодаря своей читаемости для человека и возможности автоматизации тестирования через инструменты, такие как Cucumber и SpecFlow. Хорошие критерии приёмки должны быть конкретными, тестируемыми, полными (покрывают happy path и ключевые edge cases) и согласованы до начала разработки.

Как это работает

У каждой истории пользовательского требования обычно имеются 3-7 критериев приёмки, которые охватывают различные сценарии использования продукта. Эти критерии включают сценарий успешного выполнения задачи (happy path), наиболее вероятный случай ошибки, ключевые правила валидации и любые неочевидные бизнес-правила. Формат Gherkin позволяет точно описать эти сценарии, делая их понятными как для разработчиков, так и для бизнес-аналитиков. Например, критерий может звучать так: 'Given пользователь залогинен, When он отправляет форму с пустым полем имени, Then видит сообщение об ошибке с подсвеченным полем имени'. Критерии приёмки обычно пишутся во время этапа refinement, перед sprint planning, чтобы устранить любые неоднозначности до начала разработки.

Когда применять

Критерии приёмки пишутся для каждой истории пользовательского требования, готовой к взятию в спринт. Однако, для технических рефакторинг-задач, которые не вносят видимых изменений для пользователя, критерии приёмки могут быть пропущены. Для очень маленьких историй (1-point фиксы), достаточно 1-2 критериев приёмки; для средних историй — 3-5; для больших историй, требующих 8 или более, следует разделить их до этапа sprint planning, чтобы избежать перегрузки.

Типичные ошибки

Критерии как спецификация реализации

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

Критерии написанные после разработки

Еще одна распространенная ошибка — когда критерии приёмки пишутся после того, как история была реализована. Это может привести к тому, что критерии подгоняются под уже существующую реализацию, вместо того чтобы выявлять возможные ошибки в ней. Всегда следует писать критерии до начала разработки.

Только happy path

Еще одна распространенная ошибка — когда критерии приёмки охватывают только сценарии успешного выполнения задачи (happy path), но не включают edge cases. Это может привести к тому, что непокрытые edge cases будут восприниматься как баги, что может усложнить процесс тестирования и устранения ошибок.