Критерии приемки (Acceptance Criteria)
Критерии приемки (acceptance criteria): Критерии выхода, которым должны соответствовать компонент или система, для того, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом. (IEEE 610)
Критерии приемки - это условия, которым должен удовлетворять программный продукт, чтобы быть принятым пользователем, заказчиком или, в случае функциональности системного уровня, потребляющей системой. Проще говоря - это список деталей (также известных как требования) о том, как новая функция (feature) программного обеспечения должна работать / выглядеть. Это гарантирует, что:
Функция разработана хорошо. В противном случае важный или полезный аспект может быть упущен - и никто этого не заметит до самого конца.
Это работает так, как было задумано. Если описание расплывчато, разработчикам, возможно, придется сделать предположения о том, как должна работать каждая область. С критериями приемки разработчики точно знают, какой дизайн и функциональность ожидаются.
QA знает, чего ожидать во время тестирования. Даже если функция не выглядит сломанной, она может работать не так, как хотели менеджеры по продукту. Если критерии приемки отсутствуют, тестировщики не могут сообщать о подобных проблемах.
Хорошие критерии приемки должны быть простыми для понимания, но с достаточной детализацией, чтобы убедиться, что они не слишком расплывчаты. Это не всегда универсальный подход. Но они всегда должны предоставлять достаточно информации для разработчиков, чтобы создать функцию, а для QA - для ее тестирования. Это не значит, что в процессе разработки программного обеспечения не возникнет вопросов. Но в целом функция должна быть понятной.
Формат / макет / шаблон критериев приемки (Acceptance Criteria Format/Layout/Template): существует два основных типа критериев приемки, основанные на сценариях и правилах:
Критерии приемлемости, основанные на сценариях (Scenario-based acceptance criteria), используют шаблон для подробного описания конкретного поведения / последовательности действий пользователя;
Критерии приемлемости на основе правил (Rule-based acceptance criteria) - это скорее простой список того, как функция должна выглядеть / работать;
Scenario-based acceptance criteria соответствует формату “Дано/Когда/Тогда” (“Given/When/Then”) (основан на BDD - behavior driven development):
Given /какой-то аспект, связанный с поведением пользователя/
When /пользователь выполняет определенное действие/
Then /происходит определенный результат/
Между ними в случае нескольких условий можно добавлять “И” (“AND”).
Rule-Based Acceptance Criteria - это простой список «правил» о том, как функция должна выглядеть / работать:
Все кнопки должны быть определенного цвета;
Кнопка входа должна перенаправлять пользователя в определенный раздел;
Кнопка регистрации должна находиться в определенной области;
Все кнопки должны быть серыми, если не выполняются определенные требования;
и многое другое;
Хотя критерии, основанные на правилах, имеют более простой формат, нет причин, по которым они не могут быть длинными и подробными.
Кто пишет критерии приемки? Обычно в создании критериев приемки участвуют несколько человек или команд. Тем не менее, это в первую очередь делает product manager (или “product owner”). Разработчики несут ответственность за обеспечение функциональности функции, а QA - за подтверждение ее удобства использования. Но критерии приемки создаются человеком или командой, ответственной за решение, какие новые функции добавить в продукт (независимо от типа приложения или веб-сайта).
Большая часть Agile включает внесение изменений по мере развития проекта. Так могут ли критерии приемки измениться в середине спринта? Ответ: «Это зависит от обстоятельств». Если спринт начался, но разработчики еще не завершили эту функцию, можно изменить требования. Но важно всегда сначала согласовывать с разработчиками и держать других (например, QA) в курсе. Тестировщики могли написать test cases, которые больше не актуальны после изменений. Кроме того, новый объем работы может оказаться слишком большим, чтобы разработчики могли завершить его вовремя.
**User Stories vs Acceptance Criteria: **пользовательские истории и критерии приемки идут рука об руку. Пользовательская история описывает основную цель новой функции - обзор того, как она поможет пользователям. Критерии приемки перечисляют способы работы функции с технической точки зрения. Обычно в тикетах (например, в Jira или Trello) вверху указывается пользовательская история, за которой следуют критерии приемки
Definition of Done: чтобы заявка (или функция) считалась «выполненной», все критерии должны работать. Например, предположим, что пользовательская история была: “Как пользователь, я хочу иметь возможность войти в систему, чтобы получить доступ к панели управления моей учетной записи”. Как уже упоминалось, пользователь может войти в систему, чтобы получить доступ к панели управления своей учетной записи. Но тикет не считался бы «done», если бы он также содержал следующие критерии приемки: “Кнопка входа должна быть бирюзовой”, а фактически кнопка входа была бы, например, желтой. Иногда команда решает запустить функцию даже с незначительными несоответствиями. Таким образом, они могут пометить тикет как выполненный (или создать отдельный для решения оставшихся аспектов), даже если не все критерии работают. Но с точки зрения технического определения, это не «готово», пока не пройдут все критерии приемки.
Источник: What is Acceptance Criteria?
Last updated