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

Чтобы предотвратить подобные проблемы и предоставить решение, соответствующее потребностям клиента и рынка, качественная документация по программному обеспечению должна существовать. Вот тут-то и начинают играть важную роль пользовательские истории (User Stories, US) и критерии приемки (Acceptance Criteria, AC), так как они являются основными формами документирования требований. 

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

Что такое критерии приемки и их роль в проектах?  

Критерии приемки (КП) — это условия, которым должен соответствовать программный продукт, чтобы быть принятым пользователем, клиентом или другими системами. Они уникальны для каждой пользовательской истории и определяют поведение фич с точки зрения конечного пользователя.  

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

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

Основные цели критериев приемки 

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

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

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

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

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

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

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

Типы и структуры критериев приемки  

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

• ориентированные на сценарий (шаблон Given/When/Then); 

• ориентированные на правила (шаблон чеклиста); 

• пользовательские форматы.  

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

Критерии приемки, ориентированные на сценарии  

Как следует из названия, формат критериев приемки, ориентированных на сценарии, представляет собой тип критериев приемки, который описывается в форме сценария и иллюстрирует каждый критерий. Он рассматривается через последовательность Given/When/Then (GWT) – Дано/Когда/Тогда, которая выглядит следующим образом: 

• Дано заданное предварительное условие 

• Когда я выполняю какое-то действие 

• Тогда я ожидаю какой-то результат  

Этот подход был унаследован из разработки, ориентированной на поведение (BDD) и предоставляет последовательную структуру, которая помогает тестировщикам определить, когда начинать и завершать тестирование конкретной фичи. Он также сокращает время, затраченное на написание тестовых сценариев, так как поведение системы описывается заранее. 

Шаблон критериев приемки в этом формате включает следующие утверждения: 

Сценарий – название поведения, которое будет описано  

Дано – начальное состояние сценария  

Когда – конкретное действие, выполняемое пользователем  

Тогда – результат действия в "Когда"  

И – используется для продолжения любого из трех предыдущих утверждений  

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

Рассмотрим некоторые примеры. 

Пример 1 

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

Сценарий: Забыт пароль 

Дано: Пользователь переходит на страницу входа  
Когда: Пользователь выбирает опцию <забыл пароль>  
И: Вводит действительный адрес электронной почты для получения ссылки на восстановление пароля  
Тогда: Система отправляет ссылку на указанный адрес электронной почты  
Дано: Пользователь получает ссылку через электронную почту  
Когда: Пользователь переходит по полученной ссылке в электронной почте  
Тогда: Система позволяет пользователю установить новый пароль 

Пример 2 

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

Сценарий 1: Запрос наличных средств с кредитоспособного счета 

Дано: счет является кредитоспособным 
И: карта действительна 
И: банкомат содержит наличные средства 
Когда: клиент запрашивает наличные средства 
Тогда: средства списаны со счета 
И: наличные средства выданы 
И: карта возвращена   

Сценарий 2: Запрос наличных средств с перерасходованного счета 

Дано: счет перерасходован 
И: карта действительна 
Когда: клиент запрашивает наличные средства 
Тогда: отображается сообщение об отказе 
И: наличные средства не выдаются 

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

Формат критериев приемки, ориентированный на правила 

В некоторых случаях бывает трудно вписать критерии приемки в структуру Given/When/Then (GWT). Например, GWT будет мало полезен для следующих случаев: 

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

• Целевая аудитория критериев приемки не нуждается в точных деталях тестовых сценариев. 

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

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

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

Обычно, критерии, составленные с использованием этой формы, выглядят как простой список маркеров. Давайте рассмотрим пример.   

Пример 

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

Критерии приемки базового интерфейса поиска 

1. Поле поиска размещено в верхней панели. 

2. Поиск начинается, когда пользователь щелкает "Поиск". 

3. Поле содержит подсказку серым текстом: "Куда вы направляетесь?" 

4. Подсказка исчезает, как только пользователь начинает вводить текст. 

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

6. Поиск доступен на английском, французском, немецком и украинском языках. 

7. Пользователь не может вводить более 200 символов. 

8. Поиск не поддерживает специальные символы. Если пользователь ввел специальный символ, отобразить предупреждающее сообщение: "Поисковый запрос не может содержать специальные символы." 

Другие форматы  

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

Например, ваши критерии могут быть определены как пример поведения системы:   

Этот подход предоставляет четкие рекомендации для тестирования паролей.     

Готовые шаблоны критериев приемки  

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

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

• Klariti предлагает шаблон журнала критериев приемки в формате MS Excel в составе пакета шаблонов для тестирования программного обеспечения. 

• Aha! предоставляет несколько шаблонов, которые позволяют описывать разные пользовательские истории и их критерии приемки. 

• PowerSlides включает шаблон в формате PPT с шестью динамическими дизайнами для написания простых предложений пользовательских историй и критериев приемки. 

• На Stakeholder Map вы можете скачать полностью редактируемый шаблон требований проекта в формате Excel, который включает в себя критерии приемки. 

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

Роли, ответственные и процесс создания критериев приемки  

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

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

Основные проблемы и пути их решения при написании критериев приемки 

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

Документируйте критерии до начала разработки. Критерии приемки должны быть задокументированы до начала фактической разработки. Таким образом, команда скорее всего заранее учтет все потребности клиента. В начале достаточно установить критерии для небольшого количества пользовательских историй, чтобы заполнить бэклог на два спринта (если вы используете Scrum или подобный метод). Они должны быть согласованы обеими сторонами. Затем задокументированные критерии приемки используются разработчиками для планирования технического процесса. 

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

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

Делайте критерии измеримыми и не слишком общими. Широкие критерии приемки делают пользовательскую историю неопределенной. Эффективные критерии приемки должны определить объем работы так, чтобы разработчики могли правильно планировать и оценивать свои усилия. 

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

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

Пишите критерии приемки, которые можно протестировать. Это позволит тестировщикам проверить, были ли выполнены все требования. В противном случае разработчики не поймут, завершена ли пользовательская история. 

Следуйте этим советам, чтобы научиться, как формулировать свои критерии приемки. 

Пишите в активном залоге, от первого лица. Активный залог — это когда субъект предложения выполняет действие (глагол). Соблюдение активного залога является общей рекомендацией в методологии Agile. Таким образом, критерии приемки отражают фактические слова, которые бы сказал пользователь. Использование пассивного залога может сделать неясным, кто в чем нуждается. Вместо того чтобы писать "Фильтры должны быть применены в поиске", попробуйте предоставить более информативное объяснение: "Пользователь должен иметь возможность применить набор фильтров для поиска конкретных элементов". 

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

Пишите простые и лаконичные предложения. Лучше использовать несколько простых предложений, чем одно сложное. Чем меньше ненужных слов и союзов, таких как "но", "и", "так как", в ваших критериях приемки, тем более понятными становятся требования для команды разработки. 

Заключительное слово  

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