> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/kriterii-priemki-acceptance-criteria.md).

# Критерии приемки (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](https://en.wikipedia.org/wiki/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?](https://www.mindfulqa.com/acceptance-criteria/)