Критерії приймання (Acceptance Criteria)

Критерії приймання: Критерії виходу, яким повинні відповідати компонент або система, для того, щоб бути прийнятими користувачем, замовником або іншою уповноваженою особою. (IEEE 610)

Критерії приймання - це умови, яким повинен задовольняти програмний продукт, щоб бути прийнятим користувачем, замовником або у разі функціональності системного рівня споживаючою системою. Простіше кажучи – це список деталей (також відомих як вимоги) про те, як нова функція (feature) програмного забезпечення має працювати/виглядати. Це гарантує, що:

Функція розроблена добре. Інакше важливий чи корисний аспект може бути втрачено - і ніхто цього не помітить до кінця.
Це працює так, як було задумано. Якщо опис розпливчастий, розробникам, можливо, доведеться зробити припущення про те, як має працювати кожна область. З умовами прийому розробники точно знають, який дизайн і функціональність очікуються.
QA знає, чого очікувати під час тестування. Навіть якщо функція не зламана, вона може працювати не так, як хотіли менеджери по продукту. Якщо критерії приймання відсутні, тестувальники не можуть повідомляти про подібні проблеми.

Хороші критерії приймання повинні бути простими для розуміння, але з достатньою деталізацією, щоб переконатися, що вони не надто розпливчасті. Не завжди універсальний підхід. Але вони завжди повинні надавати достатньо інформації для розробників, щоб створити функцію, а QA - для її тестування. Це не означає, що в процесі розробки програмного забезпечення немає питань. Але загалом функція має бути зрозумілою.

Формат / макет / шаблон критеріїв приймання (Acceptance Criteria Format/Layout/Template): існує два основних типи критеріїв приймання, що ґрунтуються на сценаріях та правилах:

Критерії прийнятності, засновані на сценаріях (Scenario-based aceptance criteria), використовують шаблон докладного опису конкретної поведінки / послідовності дій користувача;
Критерії прийнятності на основі правил (Rule-based aceptance criteria) – це скоріше простий список того, як функція має виглядати/працювати;

Scenario-based aceptance criteria відповідає формату "Дано/Коли/Тоді" ("Given/When/Then") (заснований на BDD - ):

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», якби він також містив такі критерії приймання: "Кнопка входу має бути бірюзовою", а фактично кнопка входу була б, наприклад, жовтою. Іноді команда вирішує запустити функцію навіть із незначними невідповідностями. Таким чином, вони можуть позначити тикет як виконаний (або створити окремий для вирішення аспектів, що залишилися), навіть якщо не всі критерії працюють. Але з точки зору технічного визначення, це не готове,

PreviousІсторії користувача (User stories)NextВиди звітів (Reports)

Last updated 2 years ago