Критерии приёмки (Acceptance Criteria, AC) — важная практика для улучшения коммуникации между разработчиками и заказчиками, а также неотъемлемая часть создания качественных пользовательских историй (User Stories) в Agile-проектах.

В статье мы рассмотрим примеры составления AC для User Story. Для составления критериев приёмки будем использовать 2 техники: свод правил и сценарно-ориентированный подход на Gherkin, основанный на методологии BDD.

Статья полезна аналитикам, владельцам продуктов, менеджерам и тестировщикам, работающим с User Stories.

Время на чтение статьи: 12 минут

Оглавление

Введение
Ценность критериев приёмки
Подходы к описанию критериев приёмки
  Критерии приёмки как свод правил
     Задаем вопросы
     Фиксируем ответы
     Дополняем список
     Прикладываем примеры
  Сценарно-ориентированный подход при описании критериев приёмки
     Использование Gherkin
     Синтаксис и примеры
Методы разработки критериев приёмки
  Product Backlog Refinement (PBR)
  Three amigos
Резюме
Об авторе

Воркшоп Сергея Медведева
«Основы бизнес-анализа и разработки
требований в Agile»

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

Посмотреть программу курса

Ценность критериев приёмки

Критерии приёмки (Acceptance Criteria, AC) — это неотъемлемая часть пользовательских историй в Agile-разработке. Критерии приёмки одинаково важны и команде разработки, и заказчику. С их помощью мы:

Определяем границы User Story
Достигаем консенсуса между командой и заказчиком о том, что именно делаем
Увеличиваем точность оценки User Story, качественно планируем занятость команды и сроки выпуска продукта

Готовим тестовые кейсы и можем автоматизировать тестирование
Выявляем негативные сценарии

Ценность критериев приёмки

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

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

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

Другая важная функция критериев приёмки — планирование и оценка задач. Они помогают команде разработчиков правильно оценивать User Story, распределять пользовательские истории между исполнителями и планировать выпуск функционала заказчику.

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

Всё это помогает сфокусироваться на реализации реальных потребностей заказчика.

Подходы к описанию критериев приёмки

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

Свод правил
Сценарно-ориентированный подход

Эти подходы не являются взаимоисключающими и могут дополнять друг друга.

Критерии приёмки как свод правил

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

Задаем вопросы

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

Как пользователь
Я хочу искать товар в пределах установленного диапазона стоимости
Чтобы найти подходящие мне товары в моей ценовой категории

Формат истории позволяет понять задачу, в ней указана роль, функционал и польза от его реализации. Мы обсудили и оценили User Story с командой, определили, что US соответствует INVEST-критериям: она не имеет зависимостей, достаточно небольшая и тестируемая.

Однако представленного описания недостаточно для передачи User Story в разработку. Поэтому мы должны задать себе вопрос: «Какие проверки должна выполнить команда перед передачей функции заказчику?»

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

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

Порядок приоритетности вопросов может зависеть от конкретных требований и условий проекта:

Вопросы 1−3 имеют большое значение для пользовательского опыта и являются ключевыми для понимания ожиданий от функции.
Вопросы 4−6 тоже важны для пользователя, но, если заказчик не готов на них ответить, эти аспекты стоит решить в команде.
Вопросы 7−10 относятся к функционалу, который может улучшить опыт пользователя и производительность системы, но не являются обязательными.

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

Фиксируем ответы

Для нашей User Story

Оформляем Acceptance Criteria в виде свода правил с учëтом ответов заказчика:

Пользователь может установить свой диапазон цены поиска при помощи бегунка, где изначальный диапазон цен соответствует минимальной и максимальной ценам товаров в выбранной категории или группы категорий.
Пользователь может установить диапазон цены с клавиатуры.
Для активации поиска пользователь нажимает кнопку «Найти».
Если пользователь вводит некорректный диапазон цен, система должна выдавать сообщение об ошибке и не показывать пустой список товаров. В приложении — примеры экранных форм и нотификаций об ошибках.
Результаты поиска должны быть точными и соответствовать установленному диапазону цен, по умолчанию отображаются в порядке возрастания цены.
Результаты поиска разбиваются по 10 штук на странице, обеспечивается переход на предыдущие или следующие страницы при помощи ссылок.
Если результаты поиска были закэшированы, то они должны быть конкретными и актуальными, с учëтом изменений в ценах на товары.
Функция поддерживает автодополнение, которое учитывает категорию товара, чтобы пользователи могли быстро выбрать подходящий диапазон цен.
Для каждой категории товаров предусмотреть предустановленные фильтры для цен: «дешёвые товары», «дорогие товары» и прочее. Варианты — в зависимости от категории — в приложении.
Результаты поиска исключают товары, которых нет в наличии и включают товары, подвоз которых ожидается.

Дополняем список

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

Важно договориться о том, какие требования к надëжности, доступности, производительности будут у разрабатываемого ПО. Например, заказчик может формулировать требования к информационной безопасности таким образом: ПО должно иметь защиту от взлома и несанкционированного доступа.

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

11. Время поиска товаров должно быть не более 3 секунд.
12. Функция поиска должна быть защищена от SQL-инъекций и атак на XSS.
13. Проверка входных данных должна быть осуществлена, чтобы предотвратить возможность межсайтовой подделки запросов (CSRF).

Прикладываем примеры

В критериях приёмки, оформленных как свод правил, мы не должны записывать все требования к интеграционным взаимодействиям, содержания выписок, выгрузок и другие подробные описания.

Чтобы передать эту информацию, гораздо удобнее приложить к User Story дополнительные артефакты или примеры, раскрывающие суть критериев приёмки: сценарии, диаграммы, описания экранных форм. Так команда будет иметь четкое одинаковое представления о том, что именно требуется сделать.

Сценарно-ориентированный подход при описании критериев приёмки

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

Подход получил своё развитие при эволюции TDD (Test Driven Development — разработка, основанная на тестировании) и появлении BDD (Behavior Driven Development — «разработка через поведение») — метода разработки, когда сначала пишутся приёмочные тесты, а потом код).

Преимущества сценарно-ориентированного подхода

Простота в написании и понимании как для разработчиков, так и для других заинтересованных сторон. Это облегчает взаимодействие между командой разработки и заказчиком.
Ориентация на требования разрабатываемого продукта гарантирует, что процесс разработки будет основываться на потребностях конечных пользователей.
Возможность повторного использования кода благодаря тому, как написаны эти сценарии. Это позволяет экономить ресурсы и использовать части этого кода при создании других тестов.

Использование Gherkin

Gherkin — это сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Gherkin описывает конкретные сценарии использования продукта.

Он широко применяется в разработке программного обеспечения для:

Документирования пользовательских сценариев
Написания автоматизированных тестов

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

Синтаксис и примеры

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

Базовый формат операторов Given, When и Then часто обогащается операторами объединения.

Допустим, мы работаем над уже знакомой нам историей:

Пример сценария, описанный в Gherkin, может иметь вид:

Каждый из пунктов — шаг сценария. В рамках одного сценария нельзя повторяться в выражениях. Обратите внимание, что язык не содержит оператора OR / ИЛИ. Тест должен давать конкретный результат, поэтому в таких ситуациях составляем ещё один сценарий.

Расширенный синтаксис Gherkin имеет на сегодняшний день более 10 выражений, и язык продолжает развиваться.

Начиная с шестой версии в Gherkin добавлен Rule — набор сценариев, позволяющих проверить не одну, а несколько функций для одного бизнес-правила. Тогда общее предусловие Given выносится «за скобки» общего набора сценариев.

Мы можем использовать критерии приёмки, описанные при помощи Gherkin, для разных целей: для автоматизации тестирования или для предоставления чëтких и понятных примеров тестировщикам и разработчикам. Важно, что независимо от того, как мы используем эти критерии, основная цель — донести логику процессов — будет достигнута.

Детальнее про Gherkin

1. Официальная документация
2. Статьи и учебники по тестированию ПО
3. Статья о сценарном тестировании

Методы разработки критериев приёмки

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

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

Существуют различные техники и процессы, которые помогают корректнее разработать критерии приёмки. Одни из самых распространëнных способов решения этой задачи — Product Backlog Refinement (PBR) и Three amigos.

Product Backlog Refinement (PBR)

Такой процесс называется Product Backlog Refinement или груминг-сессия. Это регулярная, не реже одного раза в спринт, встреча, на которой команда и владелец продукта делают обзор и оценку (в том числе переоценку) элементов бэклога, находящихся вверху списка. Scrum Guide дает такое определение: «Уточнение Product Backlog — это процесс разбиения элементов Product Backlog на более мелкие и конкретные элементы, и их дальнейшего уточнения. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер».

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

Three amigos

Регулярные встречи команды помогают договориться о том, какие Acceptance Criteria будут применены для каждой User Story и обеспечивают ясность по доставке конкретного функционала. Частоту таких встреч определяет команда.

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

Резюме

При разработке программного продукта не стоит пренебрегать критериями приёмки. За счëт своей доступности Acceptance Criteria (АС) решают множество задач, главная из которых — избежать двусмысленности и обеспечить чëткое понимание того, что должно быть достигнуто в результате работы над User Story.

В этой статье на примере одной пользовательской истории мы рассмотрели аспекты составления качественных Acceptance Criteria при помощи двух разных подходов.

AС как свод правил имеет свободный формат и может включать ограничения на функциональность, производительность, безопасность или любые другие требования, которые могут быть сформулированы в виде списка.
Сценарно-ориентированный подход — описание поведения программы через сценарии использования. Мы разобрали на примере как можно писать сценарии на языке Gherkin, расширяя условия и объединяя их общим бэкграундом.

Хотя каждая команда разработчиков имеет свой уникальный опыт, процессы и подходы к работе с User Stories, существуют best practices, которые можно использовать в своей работе. Описанные в статье примеры и подходы помогут сделать процесс разработки более управляемым.

Посмотреть программу курса

Автор

Арсланова Татьяна

Системный аналитик

15 лет в ИТ
Старший системный аналитик расчëтного центра (банк)
Ex-ведущий BA/SA, лид группы аналитиков, проекты группы компаний «Татнефть» в областях: инновационная и новаторская деятельность, НИОКР, тиражирование лучших практик, расчëт эффективности инновационных проектов
Соавтор патента «Система для управления интеллектуальными ресурсами предприятия» (RU 2 602 972 C2)
Scrum.org, Professional Scrum Master™