Команды часто применяют пользовательские истории для фиксации требований в проекте. При использовании физических карточек для сбора требований на обратной стороне они часто записывают критерии приёмки (еще их называют «условиями удовлетворения ожиданий»). Критерии приёмки - это ключевые моменты или общие правила, которые принимаются во внимание во время программирования и тестирования пользовательской истории.

Критерии приёмки - это не то же самое, что приёмочные тесты. Профессиональные тестировщики могут разрабатывать эти критерии позже для того, чтобы написать тестовые скрипты. Но сами тестовые скрипты, будь они автоматические или ручные, всегда очень детальны и конкретны, и им совершенно точно понадобится значительно больше места на карточке!

Как в самой истории на лицевой стороне карточки, на её обороте место для письма ограничено - и это сделано намеренно. История не должна описывать каждую мелочь - ни в коей мере. Во время проработки историй и написания тестов, разработчики и тестировщики должны постоянно общаться как друг с другом, так и с представителями бизнеса.

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

Критерии приёмки и тестировщики

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

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

История и критерии приёмки вместе составляют требования, тесты формируют спецификации. Требования описывают, что бизнес хочет получить в итоге, в то время, как спецификации описывают детальные параметры, как именно это надо разработать. Всегда должна быть возможность протестировать спецификации. В таких методиках, как «спецификация на примерах» и «разработка через приёмочное тестирование», спецификации разрабатываются такими, чтобы их можно было запускать в виде автоматизированных тестов.

Если владелец продукта видит, что будет полезно поговорить с тестировщиками или программистами во время написании историй и критериев приёмки, - он должен это сделать. И если тестировщики видят, что будет полезно поговорить с программистами и владельцами продуктами во время написания тестов, - они тоже должны это сделать. Команды, где поощряется подобное сотрудничество, часто именуют такие беседы «Трое друзей» или «Сила трёх». Во время подобных разговоров люди, представляющие требования, тестирование и программирование собираются вместе проговорить историю. При этом они не только обсуждают историю и критерии приёмки, они ещё и меняют их, расширяют или, наоборот, разбивают историю на несколько меньших.

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

Рассмотрим пример.

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

Такая пользовательская история может иметь следующие критерии приёмки:

Заказчики должны предоставлять валидный почтовый адрес.

Наклейка с адресом на посылке должна содержать адрес в правильном формате.

Отметим, что понятие «валидный почтовый адрес» не определено. Подобные детали можно отложить на потом, поскольку критерии приёмки - это не то место, где их нужно прорабатывать. (Исключения составляют некоторые важные и неочевидные детали, например, если нужно обязательно писать все 9 знаков почтового индекса).

Объём необходимых деталей зависит от знаний и опыта программистов и тестировщиков. Тестировщик может написать сценарий тестирования, просто опираясь на свой опыт, а программисту, предположим, понадобится разузнать, что такое «валидный почтовый адрес». Тестировщик, который никогда не бывал в стране, для которой тестируется ПО, возможно, попросит больше деталей, чем ожидает владелец продукта. В этом случае проще всего прийти к общему знаменателю, если тестировщик поговорит с владельцем продукта напрямую.

Правильный момент для определения

Меня часто спрашивают: «Когда нужно писать критерии приёмки?»

Иногда программисты отказываются оценивать усилия по истории, пока не увидят критерии приёмки - желательно расписанные очень детально. Однако владельцам продукта (и тестировщикам) нежелательно тратить время на критерии приёмки до тех пор, пока история не запланирована к исполнению. В конце концов, если на это уйдёт какое-то количество часов, а история запланирована так и не будет, то это время окажется потраченным зря.

Кроме того, если критерии приёмки заявлены, а история не поставлена в план в течение года, к тому времени и сама история, и её критерии могут поменяться. А поскольку старые критерии уже будут записаны, очень легко просмотреть потенциально важные изменения.

Я бы предпочёл, чтобы владельцы продукта не писали критерии приёмки до последнего - вплоть до самой планёрки. К тому моменту они будут уже точно уверены, чего требовать от команды. Дополнительным положительным эффектом может стать тот факт, что владелец продукта будет вынужден излагать свои мысли кратко.

Написание критериев приёмки прямо внутри итерации избавляет от проблемы отложенных или отменённых работ. Это значит, что команда должна быть готова принять - и даже, если надо, оценить - историю без критериев приёмки. Поскольку написание критериев приёмки превращается в таком случае в первую задачу в итерации до написания кода и выполнения тестов, оценка усилий должна включать в себя «составить критерии приёмки и написать код», а не просто «написать код».

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

(Тестовые скрипты, основанные на критериях приёмки, лучше всего, однако, создавать внутри итерации, предпочтительно до того, как начнётся написание кода. Написание тестовых скриптов - это часть разработки истории).

Критерии приёмки в действии

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

Автор: Аллан Келли

Оригинал: http://www.agileconnection.com/print/art[...]g-acceptance-criteria-agile-requirements

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile
• Подгруппы Agile раскрывают потенциал команды