Критерії приймання

Критерій приймання — це умова готовності

Критерій приймання описує перевірювану умову після внесення змін. Він показує, який результат вважається завершеним, і стримує агента від зайвих правок у сусідніх стилях, API чи компонентах.

Хороший критерій спостережуваний, конкретний, переважно містить одну основну умову та не залежить від внутрішньої реалізації.

Категорії критеріїв

• Функціональні — що має запрацювати.
• Негативні та граничні — чого не повинно статися.
• Сумісність — які контракти та сценарії зберігаються.
• UI / виведення — що побачить користувач і де саме.
• Технічні — які тести, логи або сигнали мають бути коректними.
• Документаційні — які підказки та інструкції потрібно синхронізувати.

Список критеріїв і Given / When / Then

Функціональні:
- За коректної причини повернення заявка створюється.

Негативні сценарії:
- Порожня або пробільна причина не запускає надсилання.

Сумісність:
- Контракт POST /api/orders/{id}/refund не змінюється.

UI:
- Під полем з’являється повідомлення про помилку.

Given: форма повернення відкрита, поле причини порожнє
When: оператор натискає кнопку надсилання
Then: запит не відправляється
And: під полем показується повідомлення про помилку

Виводьте критерії з фактів

1. Зафіксуйте affected files і поточну поведінку.
2. Опишіть спосіб відтворення проблеми.
3. Запишіть фактичний і бажаний результати.
4. Випишіть обмеження та незмінні контракти.
5. Додайте позитивний сценарій, який не можна зламати.
6. Перевірте кожен пункт після реалізації окремо.

Чого уникати

• Субʼєктивних слів без вимірюваного результату: «зручний», «кращий», «зрозумілий».
• Підміни критерію технічним рішенням: debounce, hook або конкретна функція — це спосіб реалізації.
• Обʼєднання кількох різних перевірок в один нечіткий пункт.
• Забування про поведінку, яка повинна залишитися без змін.
• Додавання зайвих критеріїв «про всяк випадок».