Критерії приймання: як визначити, що результат правильний

Після узгодження потреби й опису вимоги команді потрібне спільне правило: за якими спостережуваними ознаками можна сказати, що конкретна зміна прийнятна. Без нього слово «готово» часто означає різне для замовника, автора коду, рецензента й людини, яка користуватиметься продуктом.

Критерій приймання описує умову, яку має виконати конкретний результат, щоб його можна було прийняти. Англійською в командах часто вживають acceptance criteria (AC). Критерій зв’язує проблему й очікувану поведінку з перевіркою, але сам собою не є тестом і не доводить, що тест справді проведено.

Після цієї глави ви зможете відрізняти потребу, вимогу, критерій, перевірку та доказ; формулювати основний сценарій, заборонену дію й важливі межі; обирати метод, який відповідає типу очікування; і чесно позначати невідомий результат як неперевірений.

П’ять різних речей, які часто називають одним словом

Уявімо запит: «Зробіть картку голосування зручнішою». Тут є бажаний результат, але ще немає точної поведінки, межі прийнятності чи доказу. Розділіть ці поняття:

Рівень	На яке питання відповідає	Приклад
Потреба	Яка робота або проблема стоїть за запитом?	Відвідувачеві складно зрозуміти, яку пару він оцінює і чи зберегла система його вибір.
Вимога	Яку поведінку продукт має забезпечити?	Відвідувач може вибрати один варіант у поточній парі натисканням, дотиком або клавіатурою.
Критерій приймання	Яка умова має бути правдивою, щоб цей результат був прийнятним?	Вибраний варіант поточної пари зберігається рівно один раз, після чого показується наступна пара.
Перевірка	Що робимо, щоб оцінити критерій?	Вибрати варіант дотиком і клавіатурою; перевірити, що повторна дія не створює другого голосу.
Доказ	Що залишає перевірка?	Запис результату сценарію та версії коду, яку перевіряли.

Критерій — не просто перефразована вимога. «Відвідувач може проголосувати» не каже, що станеться, якщо подвійне натискання запише вибір двічі. Так само «є кнопка голосування» описує деталь інтерфейсу, але не підтверджує, що вибір зберігся.

Критерій не має потайки додавати функцію, якої не було у погодженій вимозі. Якщо для коректного приймання потрібне нове правило — наприклад, чи можна змінити голос після вибору, — це продуктове рішення. Його слід узгодити, зафіксувати й лише потім включити до критеріїв.

Критерій має бути спостережуваним і мати межу

Сильне формулювання дозволяє двом людям, які знають контекст, однаково визначити результат. Воно описує ситуацію, дію й очікуване спостереження, а також важливі межі: хто має доступ, які дані беруться до уваги, що означає «вчасно», як поводиться повторний запит.

Порівняйте:

Нечітко	Що неможливо вирішити	Перевірюваніше формулювання
«Пошук працює швидко»	Яке запитання, обсяг даних, середовище, час і допустима частка повільних відповідей?	На погодженому наборі з 10 000 тестових товарів 95-й процентиль часу до показу результатів не перевищує 700 мс у зазначеному середовищі.
«Дизайн гарний»	Хто оцінює і за якою підставою?	Погоджений макет відкривається на ширині 390 пікселів без горизонтального прокручування; читач може завершити названий сценарій без перекритої кнопки. Візуальну відповідність перевіряє дизайнер за прикріпленими знімками й розміром екрана.
«Система безпечна»	Які дані, роль, загроза та шлях перевіряються?	Авторизований власник бачить власний запис; користувач іншого облікового запису не може прочитати його через сторінку, прямий запит або експорт.
«Помилка обробляється правильно»	Що бачить людина і який стан лишається?	Якщо час уже зайнятий, система не змінює попередній запис, повідомляє про конфлікт і показує доступні альтернативи.

Приклад із числом 700 мс і тестовими 10 000 товарами — це погоджене навчальне припущення для конкретної демонстрації, не універсальна норма швидкодії. Інша команда має обрати поріг за реальним очікуванням людей, базовим виміром і технічними умовами.

Кількісний критерій потребує щонайменше таких уточнень:

• яку величину вимірюємо та в яких одиницях;
• на якому наборі даних і за який інтервал;
• у якому середовищі, з яким обладнанням або станом мережі;
• як рахуються пропуски, тайм-аути й помилки;
• чи йдеться про середнє значення, медіану або процентиль;
• хто й на підставі чого погодив поріг.

У прикладі пошуку команда вимірює час від натискання «Шукати» до показу результатів у тестовому середовищі. 95-й процентиль — це значення, на рівні якого або нижче лежать щонайменше 95% виміряних часів; це статистика впорядкованого набору, а не назва часового інтервалу. NIST описує кілька методів обчислення процентиля, які можуть давати трохи різні значення, особливо для малої вибірки (довідник NIST, про NIST). Тому критерій називає обраний метод. Тайм-аут — невдала відповідь: його не викидають як «неповний» і не рахують як нуль.

Коли корисний Given / When / Then

Cucumber називає Given, When і Then ключовими словами мови Gherkin. Разом вони допомагають подати сценарій як три частини:

• Given — у якому початковому стані перебуває система;
• When — яка дія або подія відбулася;
• Then — який результат можна спостерігати.

В українському поясненні це «Дано / Коли / Тоді». Наприклад:

Дано відвідувач бачить пару «Кава — Чай» і ще не голосував за неї

Коли він вибирає «Кава» й активує кнопку клавішею Enter

Тоді за цю пару записано один голос і показано підтвердження; якщо лишилися пари, з’являється наступна

Така форма допомагає погодити контекст, дію та результат без прихованих кроків. Вона особливо корисна для ролей, станів, граничних умов і сценаріїв із кількома можливими результатами. Gherkin-сценарій може водночас бути специфікацією, документацією й автоматизованою перевіркою, якщо кроки пов’язані з програмою.

Формат не робить нечіткий зміст точним автоматично. «Дано: усе налаштовано; коли: користувач продовжує; тоді: усе працює» — це лише та сама невизначеність, розбита на три рядки. А надто дрібні сценарії можуть перетворитися на сценарій клацання по кожному елементу й приховати бізнесове правило.

Gherkin описує очікування, а не внутрішню реалізацію. У сценарії показуйте результат, видимий користувачу або зовнішній системі. Перевірка бази даних може допомогти діагностиці чи безпеці, але не замінює спостереження на межі продукту.

Для простої умови природна мова або таблиця може бути ясніша. Наприклад, таблиця тарифних правил на межах кількості працівників компактніша за десять майже однакових сценаріїв. Вибирайте формат за тим, що найменше залишає простору для різного тлумачення. Cucumber окремо попереджає, що Gherkin кроки мають виражати предметну мову, а не прив’язувати сценарій до реалізації.

Основний шлях, заборонена дія, межа й повтор

Для кожної важливої вимоги поставте чотири запитання:

1. Що відбувається у звичайному успішному випадку?
2. Яка дія має бути заборонена або відхилена?
3. Який крайній стан може змінити результат?
4. Що відбувається, якщо запит повторили, запізнили або виконали паралельно?

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

Для зміни запису важливі окремі критерії можуть стосуватися:

• успішної дії: новий час вільний, підтвердження однозначне;
• конфлікту: інший клієнт забронював цей час між показом календаря й підтвердженням;
• чужих даних: користувач підмінює ідентифікатор запису в запиті;
• повтору: той самий запит надсилається двічі після повільної відповіді;
• часової межі: запит надходить саме тоді, коли консультація починається;
• застарілого стану: клієнт бачить попередню сторінку, хоча запис уже змінили з іншого пристрою.

Це приклади для відбору за ризиком, а не зобов’язання реалізувати кожен можливий варіант. У повному прикладі нижче видно, як частина цих ризиків стає критеріями, якщо інше тлумачення змінює результат.

Для кожного очікування призначте відповідну перевірку. Перевірка повторного запиту може бути автоматичною; перевірка зрозумілості повідомлення може вимагати людини; перевірка юридично чутливого правила — підтвердження відповідальної особи. Один спосіб не доводить усі аспекти результату.

Права на дані потребують і позитивного, і негативного критерію

Позитивна умова каже, хто має отримати доступ: «власник бачить свій запис». Негативна — хто не повинен його отримати: «інший клієнт не може прочитати той самий запис». Потрібні обидві: відсутність кнопки на екрані не доводить, що прямий запит або файл експорту не розкриває дані.

У критерії з правами назвіть роль, об’єкт, межу доступу й спостереження. Для особистих даних спостереження має охопити всі доступні канали, які входять у вимогу: сторінку, кінцеву точку API (Application Programming Interface — інтерфейс прикладного програмування), тобто адресу, через яку одна програма запитує дані чи дію в іншої, експорт або сповіщення. Якщо конкретний канал не перевіряли, результат не позначають як повністю підтверджений.

Критерії приймання, умови готовності задачі та умови завершення

Definition of Ready (DoR) — домовленість про те, коли задача достатньо зрозуміла, щоб узяти її в роботу. Definition of Done (DoD) — спільний опис того, що команда вважає завершеною зміною або інкрементом. DoD не те саме, що критерії конкретної історії (Atlassian).

Ці поняття відповідають на різні питання:

Артефакт	Питання	Де застосовують
DoR	Чи є в нас достатньо контексту, щоб узяти цю задачу?	До початку роботи над задачею.
Критерії приймання	Чи виконує саме ця зміна конкретні очікування?	Під час розробки й приймання цієї функції або виправлення.
DoD	Чи виконана спільна планка завершення, погоджена командою?	Для завершення різних задач або цілого інкременту, залежно від домовленості.

DoR не повинен забороняти дослідження. Якщо є істотна невідомість, команда може створити окрему коротку дослідницьку задачу: дізнатися невідоме, записати рішення й тоді уточнити критерії майбутньої роботи. Невідоме — не підстава симулювати, що воно вже узгоджене.

DoD на кшталт «код перевірено, обов’язкові перевірки пройдено, документацію оновлено» може бути корисною командною умовою завершення, але не доводить, що нова поведінка допомогла користувачеві. Команда має визначити власну планку, а не копіювати чужий шаблон як стандарт. Atlassian відрізняє загальну планку завершення від перевірки конкретної реалізації за критеріями історії.

Опис за Shape Up може зафіксувати часовий бюджет (appetite), ризики й no-gos — те, чого команда свідомо не робить. Звуження обсягу має бути явним і погодженим; не можна прибрати обов’язкову умову й оголосити той самий результат прийнятим (Shape Up, Write the Pitch).

Критерій не задає єдиний можливий тест: одне очікування може вимагати кількох перевірок, а одна перевірка — покривати кілька критеріїв. У карті простежуваності це видно:

Вимога	Критерій	Перевірка	Доказ і результат
Клієнт переносить майбутню консультацію	Клієнт може вибрати вільний час і побачити підтверджений новий час	Пройти звичайний сценарій у тестовому середовищі	Запис сценарію, версія коду, PASS або FAIL
Чужий запис недоступний	Інший клієнт не може прочитати запис власника	Перевірити інтерфейс і прямий запит під окремою тестовою роллю	Звіт перевірки доступу із замаскованими даними
Після зміни стан однаковий для обох сторін	Клієнт і адміністратор бачать той самий новий час	Перевірити обидва подання після повторного завантаження	Два знімки або записані значення й час перевірки

Таблиця допомагає знайти прогалини, але не вимагає окремої автоматизації для кожного критерію. Для фінансової чи безпекової межі зазвичай потрібен сильніший доказ, ніж для косметичної зміни.

Вимірюваність — це контракт із контекстом, а не прикраса числом

Коли результат вимірюється, визначте метрику й умови до того, як побачили зручний результат. Інакше після невдалої перевірки можна непомітно змінити вибірку, межу чи спосіб рахунку. «p95 не більше 700 мс» неповне без початку й кінця вимірювання, набору запитів, обліку тайм-аутів, конфігурації та методу розрахунку. Число без такої методики може створити лише видимість точності.

Не кожна цінність зводиться до технічної метрики. Час до відповіді можна виміряти автоматично; зрозумілість тексту — дослідити з людьми; відповідність погодженим умовам — перевірити відповідальною стороною. Якщо для метрики потрібне продуктове рішення, запишіть власника, джерело й дату. Не підставляйте середнє, поріг чи часовий період лише тому, що його легко виміряти.

Технічна метрика не доводить, що продукт корисний або зрозумілий. Marty Cagan розділяє ризики цінності, зручності, здійсненності та життєздатності; автоматична перевірка може показати, що пошук вкладається у визначений час, але не доводить, що люди знаходять товар чи бізнес досягає цілі (Cagan). Steve Krug пов’язує зрозумілість інтерфейсу з тим, чи людина може зорієнтуватися й знайти наступну дію (Krug). Для практичної перевірки попросіть учасника без підказок знайти товар через навігаційне меню й повернутися до результатів; окремо покажіть порожній каталог і запитайте, що сталося та як діяти далі. Повідомлення має пояснювати відсутність товарів і пропонувати наступний крок, наприклад повернутися до категорій або очистити фільтр. Зафіксуйте, чи людина завершила обидва завдання й як своїми словами пояснила повідомлення. Сеанс виявляє конкретну проблему, але сам по собі не доводить, наскільки вона поширена серед користувачів, чи досягнуто бізнесової цілі.

«Не перевірено» — повноцінний результат перевірки

Для кожного критерію команді потрібні щонайменше три можливі стани:

• PASS (виконано) — очікування перевірено, доказ його підтримує.
• FAIL (не виконано) — перевірка суперечить очікуванню.
• Не перевірено — доказу немає або він не відповідає на поставлене питання.

«Немає часу запустити перевірку» не є PASS. Тест, який не запускався, не є ні успішним, ні невдалим. Замість цього зафіксуйте, що саме залишилося невідомим, чому і хто вирішує наступний крок. Залежно від ризику команда може виправити проблему, додати перевірку, відкласти приймання або прийняти явне рішення про відхилення критерію. Змінювати умову після провалу можна лише через явне переглядання рішення, а не редагування чеклиста, щоб він став зеленим.

Доказ має бути пов’язаний з версією, яку оцінюють. Наприклад, запис «усе працює» не каже, який код, тестові дані чи середовище перевірено. Корисний доказ називає крок перевірки, дату, середовище та коміт або іншу стабільну ідентифікацію версії. Якщо після перевірки з’явився новий коміт, перевірте, чи доказ ще відповідає новому стану.

Повністю розібраний приклад 1. Перенесення консультації

Початковий запит: «Дайте клієнту змогу змінити час запису».

Запит не визначає межу часу, конфлікт, доступ чи повторну дію. Ми читаємо політику й наявну поведінку, а невідоме, що змінює продуктове правило, відносимо власникові рішення. У цьому навчальному прикладі власниця погодила такі правила: клієнт може змінити майбутню консультацію, лише якщо сервер отримав запит до її початку за часовим поясом Europe/Oslo; новий час повторно перевіряється під час збереження; якщо час зайнятий, чинний запис не втрачається, а система пропонує доступні альтернативи; повторне підтвердження тієї самої зміни не створює другого запис; некоректний формат часу відхиляється без зміни запису.

Вимога: клієнт може вибрати доступний час для майбутньої консультації. Якщо доступність змінилася до збереження, система зберігає старий запис і пропонує альтернативи. Новий час відображається однаково клієнтові й адміністратору.

Щоб після тайм-ауту сервер не виконав ту саму зміну двічі, клієнт повторно надсилає ключ ідемпотентності (idempotency key — ідентифікатор запиту, за яким сервер розпізнає повтор і повертає раніше збережений результат).

Критерії:

Номер критерію	Сценарій і умова приймання	Як перевірити
КР-01	Дано, що клієнт переглядає свій майбутній запис; коли він обирає доступний час і підтверджує дію; тоді запис переходить на новий час і підтвердження називає цей час.	Пройти дію тестовим клієнтом; звірити підтвердження й картку запису.
КР-02	Дано, що інший клієнт отримав запис на вибраний час після показу календаря; коли перший клієнт підтверджує; тоді його старий запис лишається чинним, а система повідомляє про конфлікт і пропонує актуальні альтернативи.	Змінити доступність між читанням календаря й підтвердженням; перевірити обидва стани та запропоновані часи.
КР-03	Дано, що клієнт намагається змінити чужий запис; коли він надсилає прямий запит або відкриває посилання на запис; тоді система не розкриває дані та не змінює бронювання.	Перевірити від імені іншого тестового облікового запису сторінку і запит.
КР-04	Дано, що сервер зберіг новий час, але відповідь клієнтові завершилася тайм-аутом; коли клієнт повторно надсилає ту саму дію з тим самим ключем ідемпотентності; тоді клієнт бачить уже підтверджений новий час, а повтор не створює другого перенесення.	Затримати відповідь після збереження, повторити ідентичний запит із тим самим ключем і звірити запис та історію.
КР-05	Дано, що сервер отримав запит у момент початку консультації або після нього за часовим поясом Europe/Oslo; тоді дію відхилено й чинний запис не змінено.	Перевірити запит безпосередньо до межі, у момент її настання й після неї.
КР-06	Дано, що форма містить некоректний час, якого немає у дозволеному форматі; коли клієнт надсилає її; тоді система пояснює помилку, не змінює старий запис і не створює нового.	Надіслати невалідний формат часу й окремо перевірити повідомлення, збережений запис та відсутність дубля.
КР-07	Дано, що перенесення завершене; коли клієнт і адміністратор повторно відкривають запис; тоді обидва бачать однаковий новий час.	Перевірити обидва подання після оновлення сторінки.

КР-05 спирається на дві погоджені межі: часовий пояс Europe/Oslo та момент отримання запиту сервером. Це конкретна політика для демонстрації, а не універсальне правило.

Карта покриття: КР-01 перевіряє звичайний шлях; КР-02 — гонку за доступність; КР-03 — межу прав; КР-04 — тайм-аут і безпечний повтор; КР-05 — часову межу; КР-06 — некоректний ввід; КР-07 — однаковий стан для клієнта й адміністратора. Один інтеграційний сценарій може охопити кілька умов, але звіт має показати, які саме. Перевірка кнопки не покриває КР-03, якщо прямий запит лишився доступним.

Що тут не є критерієм: «створити кнопку з іконкою календаря» не підтверджує, що перенесення працює; це деталь інтерфейсу, якщо лише погоджений дизайн не робить її окремою вимогою. «Має бути зручно» — не самодостатня умова, доки не названо спостережуване завдання, контекст і спосіб оцінки.

Повністю розібраний приклад 2. «Пошук має бути швидким»

Вимога: пошук у каталозі має дозволити знайти товар без помітної затримки.

Команда не повинна вигадувати число лише заради вимірюваності. Спершу з’ясуйте типові дані й очікування користувача. У цьому навчальному прикладі власник продукту погодив незмінний набір із 10 000 товарів та 1 000 зафіксованих запитів. Після 20 прогрівальних запитів той самий набір запускають п’ять разів у середовищі search-bench-01: два вузли застосунку app-01 і app-02 (кожен — 2 vCPU та 4 ГіБ пам’яті), окремий db-01 із PostgreSQL (4 vCPU, 16 ГіБ, SSD) і навантажувальний bench-client-01 з Chromium (2 vCPU, 4 ГіБ). Усі вузли розташовані в регіоні eu-north-1 та спілкуються через приватну мережу; p95 затримки мережі між клієнтом і сервісом не перевищує 5 мс. Звіт має зберегти точну версію застосунку, PostgreSQL, Chromium, конфігурацію вузлів, набір запитів та інструмент вимірювання, щоб інша людина могла повторити прогін. Усі назви, числа й розташування — вигадана конфігурація навчального прикладу, а не рекомендація для реального продукту.

Час рахують від натискання «Шукати» до показу першої сторінки. Отже, п’ять прогонів дають 5 000 вимірів; за методом найближчого рангу p95 — значення на позиції 4 750 і має бути не більшим за 700 мс. Помилки й тайм-аути фіксують окремо та вважають невдалими запитами. Поріг і метод належать лише цьому навчальному прикладу.

Критерій: p95 часу до першої сторінки не перевищує 700 мс, а всі 5 000 запитів у п’яти прогонах завершуються без помилки або тайм-ауту. Звіт містить виміри, конфігурацію та точні версії клієнта й програми.

Критерій для порожніх даних: якщо контрольний каталог не містить товарів, пошук показує повідомлення «У каталозі поки немає товарів» і доступну дію повернення до категорій; екран не лишається в стані завантаження й не показує вигадані результати. Якщо каталог має товари, але точний запит не має збігів, повідомлення пояснює саме відсутність збігів і пропонує очистити запит або фільтри. Це два різні стани, які не слід зводити до одного порожнього списку.

Перевірка: у search-bench-01 запустити 20 прогрівальних запитів, потім п’ять разів відтворити той самий набір із 1 000 запитів. Записати всі 5 000 часів, окремо порахувати помилки й тайм-аути, відсортувати успішні виміри та за методом найближчого рангу взяти значення на позиції 4 750. Додатково виконати контроль для порожнього каталогу й окремо для каталогу з товарами без збігів, бо це різні стани інтерфейсу.

Доказ: звіт зберігає ID і склад середовища, регіон і мережевий профіль, точні версії програми, бази й браузера, версію навантажувального клієнта, набір запитів, усі виміри, кількість невдалих спроб, обчислення p95 та результати обох порожніх станів. Якщо прогін використав інший регіон чи конфігурацію, зібрав менше вимірів або не зберіг метод розрахунку, це не доказ проходження критерію. Прогін на ноутбуці розробника без узгодженої конфігурації може бути сигналом для дослідження, але не відтворюваним доказом.

Цей критерій перевіряє швидкість конкретної операції за названих умов. Він не доводить, що люди знаходять потрібний товар або що бізнес досяг своєї цілі.

Повністю розібраний приклад 3. Агент змінив критерій після провалу

Початковий критерій: якщо клієнт уже використав одноразове посилання, повторне відкриття не змінює налаштування профілю і показує повідомлення про завершену дію.

Автоматизована перевірка падає: повторний запит зберігає нове значення. Агент пропонує замінити критерій на «повторне відкриття не створює другого одноразового посилання», бо тест на кількість посилань проходить.

Таке редагування змінює очікувану поведінку: критерій обмежував і повторне застосування операції, і зрозуміле повідомлення, а новий текст згадує лише створення посилання. Це не виправлення реалізації — це звуження зобов’язання після негативного результату.

Коректний процес: агент зберігає критерій і фіксує фактичну помилку. Якщо вимога однозначна, він виправляє код або тест, не змінюючи умову. Якщо політика виявилася іншою, власник рішення затверджує нову редакцію з причиною, датою й версією; після цього перевірку запускають знову. Історію попереднього результату не переписують.

Практичний порядок дій:

1. Зберегти критерій і результат FAIL у тому вигляді, як вони діяли під час перевірки.
2. Перевірити, чи тест справді спостерігав названу поведінку і чи відповідав його стан даних сценарію.
3. Якщо вимога ясна, виправити реалізацію або некоректний тест; критерій не змінювати.
4. Якщо джерело не визначало політику, передати питання власнику, а не обрати зручне тлумачення.
5. Зберегти стару та нову редакції, причину, автора, дату й версію, до якої належить нове правило.
6. Повторно перевірити актуальну реалізацію за чинним критерієм і вказати його редакцію у звіті.

Відмінність між уточненням і підміною: якщо критерій має двозначне слово, власник уточнює його до оцінки або документує нову версію. Якщо він був чітким, а код його порушив, після цього не можна викреслити незручну умову й оголосити успіх. Помилка тесту теж можлива, але для такого висновку потрібен доказ того, що тест перевіряв не те спостереження, яке назване критерієм.

Повністю розібраний реальний приклад. Візуальний критерій, якого не довів тест стилів

У відкритому репозиторії chamaya00/analytics-practice завдання #47 визначило п’ять критеріїв картки голосування: один голос за перетягуванням, вибір натисканням або клавіатурою, прокручування сторінки, підтримка зменшеного руху та відповідність широкого екрана макету (issue #47).

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

У PR #52 автор прозоро повідомив, що не має живого знімка екрана, провів лише непряме порівняння стилів і позначив візуальний критерій неперевіреним фактичним знімком. Рецензент відкрив сторінку у Chromium і знайшов, що картці бракує домінантної назви пари, отже критерій не виконано. Він також перевірив дотик, свайп і вертикальне прокручування. Автоматизовані перевірки охоплювали натискання й CSS, але звіт не містить фактичної перевірки клавіатурою; CSS-правило для зменшеного руху саме по собі також не доводить поведінку браузера (PR #52 і коментар рецензента).

Межа перевірки була конкретною: poll-dom.test.ts перевіряв натискання на панель і захист від подвійної події після жесту, але звіт не називав перевірки клавіатурою, хоча критерій вимагав Enter і Space. Щоб підтвердити цю умову, тест має сфокусувати елемент, активувати його обома клавішами й зафіксувати рівно одну подію або рецензент має пройти сторінку клавіатурою. swipe-card-css.build.test.ts шукав у CSS правило prefers-reduced-motion: reduce; це доказ зібраного стилю, а не поведінки браузера з увімкненим системним параметром. У happy-dom не було реального компонування сторінки, тож перевірка не доводила прокручування. Для цих критеріїв потрібен окремий прогін у браузері з записаними налаштуваннями, діями та результатом.

У PR #54 додали назву пари й рядок прогресу. Рецензент перевірив макет у мобільному й широкому вікнах, повторно випробував дотик, свайп і прокручування, після чого злив зміну. Він окремо позначив невелику текстову неточність поза критеріями, замість непомітно розширювати поточне завдання (PR #54).

Виправлення реалізації дало змогу повторити саме ті спостереження, яких вимагав критерій: спершу змінити композицію картки, потім перевірити її на реальній сторінці в потрібних розмірах. Дрібну текстову неточність рецензент виніс окремо, бо її не вимагав поточний критерій.

Висновок обмежений цим випадком: CSS-тест не підтверджує відображення на екрані, а наявність критерію в описі не означає, що його перевірили. Перевірка має відповідати очікуванню; «не перевірено» лишається чесним станом.

Агент допомагає уточнити критерії, але не переписує очікування на власний розсуд

Перед реалізацією агент може знайти нечітку умову або запропонувати перевірку, яка відповідає критерію. Корисні запитання до критеріїв:

• Чи відома початкова умова?
• Чи є спостережуваний результат?
• Чи названі межа, роль, дані й часовий стан, якщо вони важливі?
• Які негативний сценарій або повтор можуть змінити результат?
• Який доказ підтвердить критерій і чи відповідає він типу очікування?
• Чи не є критерій прихованою вимогою до конкретної архітектури або списку файлів?
• Чи не обіцяє формулювання висновок ширший за перевірку?

Перш ніж питати людину, агент читає задачу, документ вимог, макет, політику, код і попередні рішення. Він відрізняє поточну поведінку програми від бажаної. Якщо авторитетні вимоги конфліктують або потрібне продуктове, фінансове, приватнісне чи незворотне рішення, агент називає власника й формулює конкретне питання. Режим Plan у Codex допомагає спершу скласти план і поставити уточнювальні питання за потреби; Claude Code описує Plan mode як дослідження до редагування, коли зміни можуть бути заблоковані до схвалення. Це поведінка конкретних інструментів, яка може змінюватися; вона не передає агенту повноваження змінити прийнятний результат (OpenAI Codex, Anthropic Claude Code).

У таблиці агент може передати знайдені прогалини до початку реалізації:

Критерій	Неясність або ризик	Пропонована перевірка	Рішення потрібне?
Клієнт змінює майбутній запис	Не визначено часовий пояс на межі початку	Перевірити політику й записати межу	Так, якщо джерело її не визначає
Інший клієнт не бачить запис	Невідомо, чи охоплює вимога експорт	Знайти політику приватності й схему експорту	Так, якщо канал не охоплено
Пошук працює швидко	Немає погодженого набору й порогу	Запропонувати вимірювання на узгоджених даних	Так, власник має затвердити поріг

Агент не позначає критерій виконаним за текстом pull request, коментарем автора чи зеленим загальним набором перевірок, якщо доказ не охоплює саме цю умову. Після FAIL він повідомляє фактичний результат і зберігає критерій. Якщо політика була іншою, власник фіксує нову редакцію з причиною й версією; агент не змінює критерій, щоб перевірка стала зеленою.

Антипатерни, які приховують невиконану роботу

«Без помилок». Це важко перевірити й нічого не каже про межі системи. Назвіть важливі сценарії та допустимі спостереження.

Критерій як список змінених файлів. «Змінено booking.ts і booking.test.ts» не описує користувацький результат. Файли можуть бути доказом реалізації, але не самим критерієм.

Лише позитивний сценарій. Успішне перенесення не доводить, що інший клієнт не змінить запис, конфлікт не зітре старий час або повтор не створить дубль.

Нечітка метрика. «Швидко» плюс довільне число без даних, середовища й визначення виміру — несправжня точність.

Автоматизований тест підміняє потребу. Перевірка, що кнопка з’явилася, не доводить, що клієнт завершив дію. Перевірка зміненої таблиці може бути потрібною інженерам, але сама не підтверджує, що користувач побачив зрозуміле підтвердження.

Послаблення після FAIL. Якщо умову змінили після негативного результату, історія має показати, хто й чому змінив вимогу. Інакше це прихований зсув очікування.

Зелені перевірки подають як доказ усього. Тести підтверджують тільки те, що перевірили в своїх умовах; вони автоматично не доводять цінність, доступність, зрозумілість чи юридичну відповідність.

Як автор перевіряє готовність критеріїв

Перед передаванням перевірте:

1. Критерій випливає з погодженої проблеми або вимоги й не додає нову функцію мовчки.
2. Контексту досить, щоб дві людини однаково зрозуміли успіх.
3. Названі основний сценарій, важливі заборони, межі й повтори, що випливають із ризику.
4. Для числа задано дані, одиниці, середовище, період і обробку помилок.
5. Для прав і персональних даних є позитивний і негативний сценарії та потрібні канали.
6. Перевірка справді спостерігає очікуваний результат.
7. Доказ прив’язаний до версії; за його відсутності стан — «не перевірено».
8. DoR, критерії зміни й DoD команди не зведені до одного чеклиста.
9. Де результат залежить від політики, визначені власник, джерело й дата.
10. Рецензент може простежити шлях вимога → критерій → перевірка → доказ.

Підсумок

Критерій задає прийнятну умову для конкретної зміни; перевірка оцінює її, а доказ фіксує результат на визначеній версії. Обирайте формат і метод за тим, що саме треба побачити. Якщо умова змінилася, зафіксуйте рішення власника, а відсутність доказу позначте як «не перевірено».

Джерела та подальше читання

• Cucumber, Gherkin Reference, офіційна довідка про синтаксис Given/When/Then, сценарії, спостережувані результати та локалізовані ключові слова; перевірено 26 вересня 2026 року.
• Cucumber, Writing better Gherkin, офіційні рекомендації щодо виразних сценаріїв і предметної мови; перевірено 26 вересня 2026 року.
• NIST/SEMATECH, e-Handbook of Statistical Methods: Percentiles, визначення через впорядковані вимірювання та пояснення, що різні методи обчислення можуть давати трохи різні значення; перевірено 26 вересня 2026 року. У навчальному прикладі свідомо зафіксовано один метод, а не подано його як універсальний.
• Marty Cagan, The Four Big Risks, Silicon Valley Product Group; переглянуто 26 вересня 2026 року. Використано для розрізнення цінності, зручності користування, здійсненності й життєздатності для бізнесу.
• Ryan Singer, Shape Up: Write the Pitch, Basecamp; переглянуто 26 вересня 2026 року. Використано для контексту проблеми, appetite, ризиків і явно визначених no-gos.
• Steve Krug, Don’t Make Me Think, Revisited: A Common Sense Approach to Web (and Mobile) Usability, 3-тє видання, New Riders, 2014; сторінка автора перевірена 23 вересня 2026 року. Використано для оцінки зрозумілості навігації та повідомлень через реальні користувацькі сценарії.
• Atlassian, What is the Definition of Done (DoD) in Agile?, пояснення спільного DoD і його відмінності від критеріїв приймання конкретної історії; перевірено 26 вересня 2026 року.
• OpenAI Developers, Run long horizon tasks with Codex, 23 лютого 2026 року; Anthropic, Choose a permission mode — Claude Code Docs; перевірено 26 вересня 2026 року. Використано лише для опису інструментів планування, не як джерело продуктового повноваження.
• GitHub, chamaya00/analytics-practice issue #47, п’ять критеріїв картки голосування і запропоновані докази; створено 19 вересня 2026 року, переглянуто 26 вересня 2026 року.
• GitHub, chamaya00/analytics-practice pull request #52, опис тестування й обмеження перевірки макета; запит на злиття закрито, його замінила наступна спроба. Коментар рецензента фіксує невиконання візуального критерію; переглянуто 26 вересня 2026 року.
• GitHub, chamaya00/analytics-practice pull request #54, наступна реалізація й коментар із результатами перевірки; злито 19 вересня 2026 року, переглянуто 26 вересня 2026 року.

Тепер команда вміє називати бажану поведінку й доказ її прийнятності. Наступна тема продовжує цю роботу: як описати якість, надійність, продуктивність, безпеку й інші властивості системи, які не зводяться до однієї кнопки чи одного сценарію.