Вимоги: від acceptance criteria до UAT‑сценаріїв і тест‑кейсів

1. Про заняття і PRD

Цей розділ — про початок другого заняття: що буде за дві години і в якому порядку, а потім перший тематичний блок — PRD. Звідки береться вимога, які бувають типи вимог і як їх кодувати, чому ID вимоги не можна змінювати і як отримати чернетку PRD від AI. Заняття відкривається розбором завдання С1: тренер показує його окремо, зі звіту перевірки, тож у слайдах і в цьому конспекті розбору немає. Відгук на свою роботу С1 кожен отримує коментарем у своєму merge request.

#Вимоги: від acceptance criteria до UAT-сценаріїв і тест-кейсів

Слайд 48

С2 — друге з дев'яти занять курсу «AI-агенти в роботі QA та BA». Воно відбулося в середу, 30 вересня 2026 року, онлайн і тривало дві години. Це перше заняття, де ми працюємо з тим, що у вас щодня на столі: вимогами й тест-кейсами.

План на дві години: спершу PRD і коди вимог, потім три кроки — і кожен з AI та з перевіркою:

• знайти проблеми у вимозі, яку передають у розробку;
• переписати acceptance criteria (AC) так, щоб їх можна було перевірити;
• зібрати з AC UAT-сценарії й тест-кейси.

Теорія йде разом із демонстраціями — у Claude Code і в чаті — на демо-функції «Зміна адреси доставки». Записані прогони з відповідями AI — на сторінці демо С2, готові промпти — у шпаргалці С2. Питання на занятті пишуть у чат одразу, а тренер відповідає в паузах між блоками.

#PRD — з чого починаються вимоги

Слайд 49

Перш ніж шукати проблеми у вимозі, варто подивитися, звідки вона береться. У С1 на демо ми розбирали сирий лист власниці продукту — «хочу, щоб люди могли змінити адресу самі», а ви — такий самий матеріал свого варіанту. Сьогодні рухаємося далі по ланцюжку — до вимоги 1.0, яку вже передали в розробку.

Між листом і вимогою є крок, який часто пропускають або роблять «в голові»: PRD. Саме там кожна вимога отримує тип і ID, що не змінюється. За цим ID її потім знаходять в AC, тест-кейсах, UAT-сценаріях і баг-репортах.

#PRD — що будуємо і навіщо

Слайд 50

PRD (Product Requirements Document) — документ, з якого розробка, QA і дизайн беруть вимоги до функції: яку проблему вирішуємо, для кого, що саме робимо і в яких межах. Це не сторі і не ТЗ на один екран, а документ про функцію цілком.

Що всередині — вісім частин:

1. Проблема і мета — з метрикою успіху. Метрика — те, за чим бізнес вирішить, що функція вдалася. У демо-листі це «щоб дзвінків стало менше».
2. Користувачі.
3. Обсяг: у межах і поза межами. «Поза межами» не менш важливе, ніж «у межах»: саме там потім знаходять суперечності (розділ 2).
4. Вимоги: FR і NFR.
5. Обмеження: TC і BC. Про всі чотири типи — нижче.
6. Припущення.
7. Відкриті питання — і кому їх ставити. З адресатом, як ми вчилися ставити питання в С1.
8. Статус і версії. PRD живий, вимоги в ньому змінюються — і саме тому потрібні ID, що не змінюються.

Пише PRD менеджер продукту (PM) або BA — разом із власником продукту. Читають розробка, QA, дизайн, а тепер ще й AI-агент: йому PRD дає контекст, і що чіткіше в ньому ID і межі, то менше агент вигадує.

#Від листа до тест-кейсу — через ID

Слайд 51

Увесь ланцюжок демо «Зміна адреси доставки»:

Чесне застереження: у самому файлі вимоги 1.0 ID з PRD немає, а PRD ми записали окремо, 28.09, з того самого листа. Стрілки «→ ID PRD» — відповідність, яку провели ми, щоб показати, як ланцюжок має виглядати. У реальному проєкті кожен AC посилався б на FR чи BC, з якого виріс.

Що сталося з відкритими питаннями записаного PRD (номери — як у ньому) до моменту вимоги 1.0:

Питання 3 зникло не тому, що на нього відповіли: це рішення про обсяг, а не відповідь. А метрики успіху у вимозі 1.0 немає взагалі.

#FR · NFR · TC · BC — чотири типи вимог

Слайд 52

«Швидко», «надійно», «інтуїтивно» — не вимога, а побажання: тест не скаже «пройдено».

Як розрізняти, коли сумніваєтесь: FR можна показати на екрані; NFR можна виміряти; TC вирішує технічна команда; BC вирішує бізнес.

#TYPE-AREA-NN: ID на все життя вимоги

Слайд 53

Код складається з трьох частин: тип · область · номер. FR-ADDR-03 — третя функціональна вимога про адресу. Область — коротке слово латиницею (ADDR, PAY, SEARCH): з ID одразу видно, про що вимога, а номери в різних областях не заважають одне одному.

Правила — головне в цій темі:

• ID не змінюється весь життєвий цикл вимоги. Не перенумеровуємо, коли щось видалили чи вставили посередині, і не віддаємо номер іншій вимозі — інакше посилання в AC, тест-кейсах і баг-репортах почнуть вказувати не туди.
• Відкинута вимога не зникає, а лишається зі статусом dropped. Тоді видно, що її розглядали і чому від неї відмовились.
• Зміна — на місці: той самий ID, поруч дата і рішення.
• Похідна вимога посилається на джерело, з якого виросла.
• Phase (MVP · Future) — коли робимо; Status (proposed · accepted · shipped · dropped) — чи погоджено й зроблено. Це різні речі.

Приклад зі справжнього документа іншого проєкту тренера. Вимоги в ньому переносять ID з PRD замовника дослівно, а специфікації, тести й записи демо посилаються саме на ці ID. Цитати — англійською, як в оригіналі:

NFR-PERF-02   Lighthouse Performance ≥ 90 on production URL…
BC-PRIVACY-02 Geolocation only via explicit user action…
FR-SEARCH-06  «Use my location» — Derived from BC-PRIVACY-02…
TC-STACK-05   (amended 2026-06-22 by user decision, ADR-0006…)

Тут видно всі чотири типи, поріг у NFR (≥ 90), похідну вимогу з посиланням на джерело і зміну на місці з датою й рішенням. Область у граматиці тієї схеми необов'язкова, але ми її завжди ставимо.

#Промпт: PRD із сирого запиту

Слайд 54

Промпт складається з тих самих п'яти частин, що в С1: роль, вхідні дані, задача, критерії приймання, формат. На слайді він скорочений; повний текст — нижче і в шпаргалці С2:

Роль: ти — бізнес-аналітик; готуєш PRD (Product Requirements Document) — документ, з якого розробка, QA і дизайн беруть вимоги до функції.

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

Задача: склади PRD функції за форматом нижче.

Критерії приймання:
- кожна вимога має стабільний ID: FR-<ОБЛАСТЬ>-NN — функціональні, NFR-<ОБЛАСТЬ>-NN — нефункціональні, TC-<ОБЛАСТЬ>-NN — технічні обмеження, BC-<ОБЛАСТЬ>-NN — бізнес-обмеження; область — коротке слово латиницею (ADDR, PAY, UI…), NN — 01, 02…;
- одна вимога — одне твердження, яке можна перевірити; біля кожної — джерело: коротка цитата з листа або позначка «припущення»;
- чисел, строків і правил, яких у листі немає, не вигадуй — пиши «[питання до автора: …]»;
- NFR — лише з вимірюваним порогом; якщо порогу в листі немає — «[поріг — питання до автора]»;
- суперечності в листі не вирішуй сам: винеси їх у «Відкриті питання» з варіантами рішення.

Формат відповіді (Markdown):
1. Проблема і мета — з метрикою успіху, якщо вона є в листі.
2. Користувачі.
3. Обсяг: у межах і поза межами.
4. Вимоги — чотири таблиці FR, NFR, TC, BC: «ID | Вимога | Джерело».
5. Припущення.
6. Відкриті питання — що спитати і в кого.

===
<вставте запит>
===

Головна робота — у критеріях приймання: кожен рядок закриває типову помилку AI.

• Стабільний ID із типом і областю — щоб на вимогу можна було послатися.
• Цитата з листа біля кожної вимоги — щоб відрізнити сказане від домисленого.
• «Не вигадуй чисел» — AI охоче допише час відповіді чи ліміт змін, яких у листі немає.
• NFR лише з порогом — інакше отримаємо «система має працювати швидко».
• Суперечності не вирішувати — рішення за автором, не за моделлю.

У чаті запит вставляють під промптом між рядками ===, так само як вимогу в демо розділу 2. Для сирого, короткого запиту є варіант: додайте на початок «Спершу постав мені до 7 уточнювальних питань, потім склади PRD». Ви відповідаєте на питання — і лише потім отримуєте PRD, у якому менше квадратних дужок.

#Демо: PRD із листа — що перевірити

Слайд 55

Це не живе демо, а справжній прогін, записаний 28.09.2026: Claude Code у неінтерактивному режимі (claude -p), модель claude-sonnet-5, промпт вище разом із демо-листом, без файлів та інструментів. Записані прогони — на сторінці демо С2. Усі вимоги з відповіді, рядки дослівно:

Під таблицею BC модель сама додала: «BC-PAY-01 і BC-PAY-02 суперечать одне одному — див. „Відкриті питання“».

Що зроблено добре:

• Джерела — з листа, нічого не вигадано, зокрема P.S. про зміну отримувача. Але лапки ще не означають «дослівно»: дві цитати трохи переказані — у FR-ADDR-03 («зміна має працювати…» замість «щоб зміна працювала…») і в BC-PAY-02 (зшито з двох фрагментів листа). Де цитати немає, AI так і пише: у TC-ADDR-01 джерело — «випливає з FR-ADDR-03» плюс питання до автора.
• Суперечність не вирішив сам: записав обидві вимоги як BC-PAY-01 і BC-PAY-02, позначив конфлікт і виніс у відкрите питання 1 з трьома варіантами. Саме це ми й просили.
• Порогів не вигадав: у метриці успіху й у NFR стоїть «[поріг — питання до автора]».

Що не так — дві хибні класифікації:

• NFR-CALL-01 «дзвінків має стати менше» — це метрика успіху, бізнес-мета функції; вона вже стоїть у розділі «Проблема і мета». NFR описує якість системи — швидкодію, доступність, — а не бізнес-результат.
• TC-ADDR-01 «система має визначати статус, щоб заблокувати зміну» — це правило поведінки, тобто FR (доповнення до FR-ADDR-03), а не технічне обмеження: стек чи інтеграцію воно не описує.

Ще одне: FR-RCP-01 — зміну отримувача з P.S. — AI поставив «у межах». Це не вигадка, у листі так і написано, але це рішення про обсяг; у вимозі 1.0 зміну отримувача винесли «Поза межами».

Цифри прогону: 4 FR, 1 NFR, 1 TC, 3 BC і 7 відкритих питань; 90 с і 0,11 $ за прейскурантом (total_cost_usd). Вхід — 10 552 токени: 2 нових, 7 153 записано в кеш і 3 397 прочитано з кешу; вихід — 8 026 токенів, з них 5 449 — «роздуми» моделі. Промпт разом із листом — 2 683 символи.

#ID — нитка через усі артефакти

Слайд 56

ID потрібен не для краси. Він проходить через усі артефакти: вимога в PRD → AC, що з неї виріс → тест-кейс і UAT-сценарій, що перевіряють AC → баг-репорт, що посилається на AC і вимогу. Ілюстрація на демо:

BC-PAY-02 (30 грн) → AC3 → TC-08 · UAT-03 → баг-репорт → AC3 · BC-PAY-02

TC-08 і UAT-03 тут умовні, з розділу 4. І TC-08 — це тест-кейс, а не технічне обмеження: той самий випадок, що в попередній темі.

Коли ID є всюди, три перевірки робляться механічно — людиною чи AI:

Далі в курсі: у С3 ці ID підуть у задачі трекера; у С4 специфікація стане контрактом в OpenSpec — зі статусами і змінами через propose → apply → archive, тобто та сама контрольована еволюція, що й «зміна на місці з датою і рішенням»; у BA1 — декомпозиція епіка на сторі з трасуванням до вихідного запиту; у BA3 і QA-заняттях — консистентність усього пакета вимог.

2. Проблеми у вимогах

Цей блок — про те, як знайти проблему у вимозі раніше, ніж на ній збудують код і тести. У ньому три види проблем, перевірка сторі за INVEST, прийом «а що якщо» для межових випадків і уточнювальні питання, на які автор відповість одним рішенням. Усе показано на демо-вимозі «Зміна адреси доставки», а наприкінці те саме робить AI, і ми звіряємо його відповідь зі списком проблем. Це основа розділів 2 і 3 звіту С2.

#Одне речення — три прочитання

Слайди 57 і 58

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

Приклад — AC5 демо-вимоги, яку розбираємо далі: «Зміна недоступна менш ніж за 24 години до очікуваної дати доставки…». У посилки є дата доставки, але немає часу, тож «24 години до дати» кожен домислює сам:

Це можливі прочитання, а не записи реальних розмов. Три люди — три продукти, і жоден не помилився в читанні: помилка в самому реченні.

#Вимоги — ваша щоденна робота

Слайд 59

Цифри — з вхідного опитування когорти (вересень 2026, 61 відповідь з 71: 41 BA і 20 QA; лише агреговані дані):

Дві знеособлені цитати з відповідей. BA: «вичитка великих об'ємних BRD, згенерованих бізнесом через AI». QA: «аналіз вимог у задачі, пошук кейсів, які можуть бути не покриті вимогами». Перша показує, що вимоги вже пише AI, а вичитувати їх доводиться вам. AI пише гладко й упевнено, але з тими самими видами проблем, які розібрано нижче. Друга для QA — буквально зміст цього заняття.

#Демо-вимога: зміна адреси доставки

Слайд 60

Функція та сама, що в демо С1, але документ новий: вимога версії 1.0, яку вже передали в розробку й тестування. Тож питання не «що хоче замовник», а «чи можна за цим документом розробляти й тестувати без здогадок». Скорочений переказ, як на слайді:

Сторі. Як отримувач, я хочу змінити адресу доставки в застосунку і зробити нове відділення основним у профілі…
AC1 кнопка «Змінити адресу» — у статусах «Прийнята» і «В дорозі», у застосунку або на сайті
AC2 відділення й поштомати того самого населеного пункту; список — зручно, пошук — швидко
AC3 не більше двох змін: перша безкоштовна, друга — 30 грн карткою до підтвердження; оплата не пройшла — адреса попередня
AC4 після другої зміни кнопка неактивна, під нею текст
AC5 менш ніж за 24 години до очікуваної дати — змінити не можна
AC6 підтвердив → «Адресу змінено», нова адреса й нова дата
AC7 нове відділення автоматично стає основним у профілі
Поза межами: зміна адреси на сайті, зміна отримувача; посилки з післяплатою — без кнопки

Повний текст — materials/demo/change-address/requirement.md у репозиторії gitlab.com/koldovsky/ai-qa-ba-c2. Там є ще розділ «Контекст» (зараз адресу змінюють лише через контакт-центр, версія 1.0 переносить це в застосунок) і нотатки. У вашому варіанті структура та сама, але функція «Пакунку» своя і проблеми свої — не ті, що в С1. Робота за демо-варіантом не зараховується.

#Три види проблем у вимозі

Слайд 61

• Неоднозначність. Розробник не знає, що будувати, а QA — що перевіряти. Питання: як сортуємо і групуємо список, що шукаємо (адресу, номер відділення), який час відповіді пошуку допустимий. Сюди ж належить межа без точки відліку, як 24 години в AC5.
• Неповнота. AC3 і AC6 описують лише успішний шлях. Що бачить отримувач, чи застосовано зміну і що з оплатою, якщо посилка прибула у відділення або настала межа AC5 посеред оформлення, — у вимозі жодного слова.
• Неконсистентність. Сторі й контекст говорять лише про застосунок, AC1 додає сайт, «Поза межами» сайт виключає. Розробник сайту зробить кнопку або ні — залежно від того, який абзац прочитав першим.

Ті самі види стоять у стовпці «Тип» таблиці проблем шаблону звіту С2 (розділ 2), третій там названо «суперечність». Ще два типи, INVEST і межа, — далі.

#INVEST: чи готова сторі до розробки

Слайд 62

INVEST — шість питань не до окремого речення, а до сторі цілком:

Демо-сторі не відповідає двом критеріям:

• S. Одна сторі — дві можливості: змінити адресу однієї посилки і змінити основне відділення в профілі (AC7), що діє на всі наступні посилки. У другої свої ризики: отримувач міг змінити адресу один раз, скажімо у відрядженні, і не очікує, що туди поїдуть і всі наступні посилки. Їх можна оцінити й випустити окремо, тож це дві сторі. «Сторі завелика» і «AC7 — окрема сторі» — два правильні формулювання однієї проблеми. Через I її не пояснюйте: I — про незалежність від інших сторі, а тут забагато в одній.
• T. В AC2 зі «зручно» і «швидко» немає критерію, за яким тест скаже «пройдено». Це та сама неоднозначність, лише INVEST ловить її з іншого боку.

N, V і E — питання радше до команди, ніж до тексту; для демо вони проходять. Пункт L2 для BA «пакет сторі за INVEST» — саме такий розподіл завеликої сторі.

#«А що якщо…» — межові випадки

Слайд 63

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

Межа значення — це «рівно», «трохи менше», «трохи більше»: для QA це готові межові тест-кейси, для BA — питання, без якого їх не написати. Стан, що змінюється посеред дії, — найчастіша прогалина в потоках з оплатою чи підтвердженням; ця ситуація повернеться в блоці про баг-репорт (слайд 89). Збій посередині — гроші списано, а дію не виконано. «Порожня» дія нічого не змінює, але може з'їсти ліміт. Наслідок — коли одне правило змінює вхідні дані іншого.

Фразу нижче можна додати в промпт. Останнє речення в ній важливе: ви просите питання, а не правила. Інакше AI охоче «допише» вимогу, і його вигадка виглядатиме як рішення.

Для кожного AC назви ситуації «а що якщо», яких вимога не описує: межі, зміну статусу посеред дії, збій оплати. Лише питання — без готових правил.

#Одне питання — одне рішення

Слайд 64

Добре уточнювальне питання — таке, на яке автор відповість одним рішенням: «так», «ні» або вибором варіанта. Формула: де (номер AC) → яка ситуація → варіанти А / Б → кому.

«Уточніть AC5» перекладає роботу на автора: він не знає, що саме вам неясно. Добре питання називає обидва прочитання. Для суперечності назвіть обидва місця і попросіть вибрати одне. Для неповноти найкраще працює запропонована відповідь, позначена як пропозиція. «Кому» теж важливо: питання про гроші не адресують тому, хто відповідає за інтерфейс. У звіті С2 таких питань щонайменше три (розділ 3). Вигадка AI часто ховається в «компромісному» варіанті всередині питання: модель пише «можливо, варто дозволити…», і за тиждень це вже читається як правило.

#Демо 1: проблеми і питання до автора

Слайд 65

AI отримує демо-вимогу і промпт із тих самих п'яти частин, що в С1. Мета — показати, що з таким промптом AI знаходить проблеми і ставить питання, але результат усе одно треба звірити з вимогою. Промпт зі слайда:

Роль: ти — бізнес-аналітик на рев'ю вимоги перед розробкою; результат читатимуть автор вимоги, розробка і QA.
Вхідні дані: файл requirement.md — сторі, AC1–AC7, нотатки, «Поза межами». Працюй лише з ним.
Задача: знайди проблеми вимоги і до кожної сформулюй уточнювальне питання.
Критерії приймання:
- тип — один із: неоднозначність, неповнота, суперечність, INVEST, межа;
- кожна проблема посилається на AC, сторі чи розділ;
- на кожне питання автор може відповісти одним рішенням;
- правил, яких у вимозі немає, не додавай; варіант відповіді позначай «пропозиція».
Формат: таблиця «де · тип · що не так · питання · кому», до 10 рядків.

В агенті — нова сесія (/clear) у теці лише з requirement.md і в кінці рядок «Файл requirement.md — у поточній теці. Інших файлів не відкривай.» У чаті — текст вимоги між рядками ===.

Відповідь перевіряють трьома питаннями:

1. Скільки з п'яти? AC2 «зручно / швидко», зміна статусу посеред оплати, сайт, дві можливості в сторі, 24 години. Інші обґрунтовані «а що якщо» в цьому потоці теж знахідки: обрано поточне відділення, обраний поштомат закрито, оплата пройшла, а зміну не збережено.
2. Одне рішення? На яке питання автор не зможе відповісти «так», «ні» чи вибором? Його переписують за формулою з попереднього розділу.
3. Що додано від себе? Типові вигадки тут — push- чи SMS-сповіщення, скасування вже зробленої зміни з поверненням 30 грн, обмеження за часом доби, перевірка адреси за геолокацією, зміна отримувача чи сайт як частина обсягу. У «пропозиції» — нормально, як факт вимоги — вигадка.

Найімовірніше, AI знайде AC2, сайт і 24 години: їх видно в тексті. Неповноту і INVEST він може пропустити або сформулювати загально — це матеріал для блоку про перевірку згенерованого (слайд 81).

Записаний прогін (26.09.2026, Claude Code, модель Claude Sonnet) зроблено з промптом зі шпаргалки С2. Каркас той самий, але вимогу вставлено між ===, промпт просить щонайменше п'ять питань, а формат — таблиця «№ · Де · Цитата · Тип · Чому проблема» і окремий список питань, без ліміту рядків. Тому відповідь довша, ніж просить слайд: за 41 секунду — 14 проблем і 15 питань.

Що ще видно за тими самими трьома питаннями:

• Додаткова знахідка. Рядок 10: якщо діють і AC4, і AC5, кнопка неактивна з двох причин, а тексти під нею різні — який показувати, не сказано. Решту рядків (післяплата, «початкова адреса» після першої зміни, зміни через контакт-центр) так само звіряйте з вимогою.
• Що виправити. Рядок 1 позначено «Small, Independent», а проблема — саме S. До того ж AI пише, що дві можливості «не можна розробити, випустити й перевірити окремо», хоча аргумент за розподіл якраз у тому, що їх можна випустити окремо. Рядок 14 записує в порушення T те, що AC2–AC5 без Given/When/Then; але AC може бути й однозначним твердженням (так і в шаблоні звіту), тож неперевірюваним AC2 роблять «зручно» і «швидко», а не формат.
• Питання на кілька рішень. Питання 12 питає разом про точку відліку, часовий пояс і «рівно 24 години», тож його розбивають на окремі питання — як у зведенні нижче.
• Від себе. Жодної типової вигадки як факту вимоги немає. Автоматичне повернення коштів з'являється лише як питання 9, і так само лише питанням (14) AI пропонує дати користувачу вибір для AC7.

Повна відповідь — на сторінці демо С2.

#П'ять проблем — п'ять питань

Слайд 66

Зведення за демо-вимогою: п'ять проблем і по одному питанню на кожну. Типи — ті самі, що в стовпці «Тип» шаблону звіту.

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

AC5: 24 години рахуємо від 00:00 очікуваної дати чи від прогнозованого часу прибуття?
AC5: рівно за 24 години до очікуваної дати зміна ще доступна — так чи ні?
AC5: після зміни зсунулась дата доставки — межу рахуємо від нової дати?

Для L3 у sources.md демо-варіанту є ще конфлікт джерел про те, коли зміна взагалі дозволена; це вже рішення про саме правило, а не уточнення межі.

У вашому варіанті проблеми інші — не шукайте там цих самих. Далі ланцюжок такий: питання → рішення автора → новий AC. Як записати його перевірювано — наступний блок (слайд 67).

3. Acceptance criteria

Цей блок — про те, як перетворити вимогу на acceptance criteria, за якими можна однозначно сказати «пройдено» або «не пройдено». Попередній блок закінчився проблемами у вимозі й питаннями до автора. Тут наступний крок: переписати розмиті AC так, щоб їх можна було перевірити, записати їх у форматі Given/When/Then, розкласти кожне правило на позитивні, негативні й межові AC і знайти межі, яких вимога не визначає. Наприкінці — промпт, яким цю роботу можна доручити AI, і чек-лист, за яким ви перевіряєте результат, перш ніж під ним підписатися. Усі приклади — на демо-вимозі «Зміна адреси доставки», версія 1.0 (materials/demo/change-address/requirement.md у репозиторії практики).

#AC — домовленість, яку можна перевірити

Слайд 67

Acceptance criteria — не побажання до функції, а умова, за якою розробник, тестувальник і бізнес однаково скажуть «готово» або «ні». Це домовленість трьох сторін: розробник знає, що будувати, тестувальник — що перевіряти, бізнес — що приймати. Якщо троє читають той самий AC і уявляють різне, домовленості немає, хоч би як гарно його написано.

Далі — п'ять кроків: від розмитого AC до перевірюваного, форма Given/When/Then, три групи AC (позитивні, негативні, межові) і пошук меж, промпт для AC і перевірка того, що написав AI.

Проблеми цієї вимоги ви вже бачили в демо 1 (слайд 65). Тепер видно, як знайдені проблеми й відповіді на питання перетворюються на AC.

#Від розмитого — до перевірюваного

Слайд 68

Два приклади з демо-вимоги — AC2 і AC5. Ліва колонка — як написано в requirement.md, середня — чому це не перевірити, права — той самий AC у вигляді, який можна перевірити.

AC2. «Швидко» і «зручно» кожен читає по-своєму: розробник вважає, що дві секунди — це швидко, а бізнес мав на увазі «миттєво». Тест на такий AC завжди пройде або завжди впаде — залежно від того, хто тестує. Переписати AC не означає вигадати число. Число дає автор вимоги; доки його немає, в AC стоїть питання до автора — і це чесніше, ніж «2 секунди» від себе.

AC5. Тут проблема тонша: «за 24 години до дати», а в дати немає часу. Рахувати від 00:00? Від початку роботи відділення? Від прогнозованого часу прибуття? Права колонка показує AC за умови, що автор відповів «від 00:00». Позначка про припущення під ним — не формальність: без неї хтось сприйме припущення як рішення. Якщо питання про цю межу ви поставили в попередньому блоці, саме так відповідь на нього стає AC.

Звідси простий тест на перевірюваність: дайте AC двом людям, наприклад розробнику й тестувальнику, і спитайте кожного окремо, чи пройдено. Якщо відповіді можуть розійтися, AC ще не готовий. Привід зупинитися й перечитати AC — слова-сигнали: «зручно», «швидко», «коректно», «за потреби», «тощо».

#Given / When / Then — три питання до AC

Слайд 69

Праву колонку попереднього слайда записано у форматі Given/When/Then. Кожна частина відповідає на своє питання. Розберемо AC6 демо-вимоги — він уже записаний у цьому форматі:

AC6. Given отримувач обрав нове відділення чи поштомат, When він підтверджує зміну, Then бачить повідомлення «Адресу змінено», а в картці посилки — нову адресу й нову очікувану дату доставки.

Що це означає на практиці:

• Given — усе, що треба підготувати, щоб тест узагалі можна було запустити: статус посилки, номер спроби, дата доставки. Кожна умова в Given потім стає тест-даними. У AC6 Given каже лише «обрав нове відділення», але результат залежить від того, перша це зміна чи друга, платна, і який зараз статус посилки.
• When — одна дія або одна подія. Якщо в When написано «обирає, оплачує і підтверджує», це кілька AC, склеєних в один: коли тест упаде, ви не знатимете, на якому кроці.
• Then — те, що видно або можна виміряти: текст повідомлення, значення в картці, стан кнопки. «Система коректно обробляє запит» — не Then.

GWT — форма, а не гарантія. AC1 демо-вимоги записано в Given/When/Then бездоганно, але його «в застосунку або на сайті» суперечить розділу «Поза межами», де зміну адреси на сайті виключено. Правильна форма не робить вимогу правильною: зміст AC однаково звіряють з рештою документа.

Given/When/Then — не обов'язковий формат. Однозначне твердження, яке можна перевірити, теж підходить; так само сказано і в шаблоні звіту С2 (templates/c2-report.md, розділ 4).

#Позитивні, негативні, межові

Слайд 70

На одне правило потрібен не один AC, а три групи. Усі три приклади — з демо-вимоги; у дужках — AC, на які спирається приклад.

Позитивний — працює. Умови виконано, результат настає. Такий AC доводить, що функція працює, і саме такі AI пише охоче й багато.

Given посилка «В дорозі», змін ще не було, обрано інше відділення того самого населеного пункту
When отримувач підтверджує зміну
Then «Адресу змінено», у картці — нова адреса, оплати немає
(AC1 · AC3 · AC6)

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

Given одну зміну вже зроблено
When оплату 30 грн за другу зміну відхилено
Then у картці — попередня адреса
(AC3)

Межовий — край правила. Остання дозволена дія і перша заборонена: друга зміна ще можлива, третя — ні, і на межі є конкретний текст з AC4.

Given дві зміни вже зроблено
When отримувач відкриває картку
Then кнопка неактивна, під нею «Ви вже змінили адресу максимальну кількість разів.»
(AC4)

Для QA це знайомі класи еквівалентності й межові значення. Для BA — ті самі «а що якщо» з попереднього блоку (слайд 63), записані як AC. Без підказки AI пише здебільшого позитивні AC: як і в С1, модель тяжіє до «щасливого шляху». Лікується це одним рядком у критеріях приймання промпту — три групи треба просити явно. Цей рядок є в промпті для AC нижче.

#Межа — там, де правило змінює відповідь

Слайд 71

Межа — там, де правило змінює відповідь з «можна» на «не можна». У вимогах вона ховається в чотирьох місцях: числа («24 години»), лічильники («дві зміни»), статуси («Прийнята», «В дорозі» — і все інше) і переліки («той самий населений пункт»). Для кожної межі перевіряють три точки: до межі, на межі і за межею. У таблиці — три межі демо-вимоги.

• Кількість змін — легкий випадок: межа чітка, і вимога відповідає в усіх трьох точках.
• Час. «Менш ніж за 24 години» — рівно 24 години ще можна чи вже ні? А від якого моменту рахувати ці 24 години, вимога теж не каже — це ми вже бачили. Відповіді немає, тому в клітинці «?».
• Статус — найцікавіший рядок. Отримувач почав зміну, поки посилка була «В дорозі», обирає відділення, оплачує 30 грн — а посилка тим часом прибула. Що він бачить? Чи застосовано зміну? Що з оплатою? Вимога мовчить.

Ще одне таке місце — на перетині двох правил: після другої зміни і менш ніж за 24 години до дати доставки кнопка неактивна з обох причин, а тексти в AC4 і AC5 різні. Який із них показувати, вимога не каже.

#Промпт для AC: критерії — під AC

Слайд 72

Промпт складається з тих самих п'яти частин постановки задачі, що й у С1 (слайд 21). Змінюються лише задача і критерії приймання: тепер вони описують хороший AC.

Роль: ти — бізнес-аналітик; готуєш acceptance criteria для розробки й тестування.
Вхідні дані: requirement.md у поточній теці і мої уточнення нижче. Працюй лише з ними, інших файлів не відкривай.
Задача: перепиши AC1–AC7 так, щоб кожен можна було перевірити.
Критерії приймання:
- Given/When/Then; у When — одна дія, у Then — лише те, що видно або можна виміряти;
- для кожного правила — позитивний і негативний AC, де є межа — межовий;
- кожен AC посилається на пункт вимоги або на моє уточнення;
- чисел і правил, яких немає у вхідних даних, не додавай — пиши «[питання до автора: …]».
Формат: таблиця «ID · Given · When · Then · тип · джерело»; під нею — «Питання до автора».

Кожен критерій — правило з попередніх слайдів:

1. Given/When/Then з двома уточненнями: одна дія в When і лише спостережуваний Then.
2. Три групи, щоб отримати не лише «щасливий шлях».
3. Посилання на пункт — як у С1: кожен AC стає перевірюваним за секунди, бо видно, на що він спирається.
4. Головний рядок — «не додавай, пиши питання». Саме він відрізняє переписаний AC від вигаданого: без нього AI заповнить «швидко» власним числом.

«Мої уточнення» — це відповіді автора на ваші питання з попереднього блоку. У роботі їх дає автор вимоги. У завданні С2 автора немає, тож пишіть власні рішення з позначкою «припущення»: так чесно, і так видно, де AC ще треба погодити. Для демо-вимоги таким уточненням може бути одне припущення: «межу AC5 рахуємо від 00:00 дати доставки».

Промпт написано для агента, який читає requirement.md з поточної теки. Агента зручно запускати в окремій теці, де лежить лише ваша вимога, — так він працюватиме саме з нею, а фраза «інших файлів не відкривай» лише підстрахує. У чаті замість назви файлу вставте текст вимоги між рядками ===, а уточнення — під ним.

Записаний прогін. На сторінці демо С2 є справжня відповідь AI на схожу задачу: Claude Code, модель Claude Sonnet, запис 26.09, текст вимоги вставлено в промпт. Промпт там інший, ніж на слайді: він одразу просить і AC, і UAT-сценарії, AC просить подати нумерованим списком AC1…ACn, колонки «джерело» в ньому немає, а критерії для AC такі:

- AC у форматі Given / When / Then, без слів без міри («швидко», «зручно») — або число, або позначка «відкрите питання»;
- щонайменше один негативний і один межовий AC;
- де відповідь залежить від рішення автора вимоги, познач «відкрите питання» і не вигадуй рішення;

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

• «зручно» і «швидко» AI не перетворив на число: AC4 у відповіді — лише перелік значень, потрібних від автора, і фраза «Перевірний AC не формулюю, поки цих значень немає»;
• межу 24 годин (AC9 у відповіді) записано з обох боків, з поясненням «за буквальним „менш ніж 24 години“ рівно 24:00 ще дозволено» і питанням, від якого моменту рахувати;
• для неуспішної оплати AI записав, що лічильник змін не збільшується, але сам позначив це як «припущення для підтвердження автором»;
• правило про післяплату з «Поза межами» перенесено в Given, а суперечність між «на сайті» в AC1 і розділом «Поза межами» винесено у відкрите питання.

Повна відповідь разом з UAT-сценаріями — на сторінці демо, промпти для кожного кроку завдання — у шпаргалці С2.

#AI пише AC — підписуєтесь ви

Слайд 73

Ось як може виглядати відповідь AI на промпт для AC. Це ілюстрація, складена з типових помилок, а не запис конкретної сесії:

AC1.1 Given посилка «В дорозі», When отримувач відкриває картку в застосунку, Then бачить кнопку «Змінити адресу». · AC1
   ↑ є опора в AC1, Then видно
AC2.1 Given відкрито пошук, When отримувач вводить адресу, Then результати з'являються за 2 секунди. · AC2
   ↑ «2 секунди» у вимозі немає — це питання до автора
AC5.1 Given до дати доставки менше 24 год, When отримувач натискає «Змінити адресу», Then система коректно обробляє запит. · AC5
   ↑ «коректно» не перевірити; за AC5 кнопка неактивна
AC8 Given отримувач за геолокацією поза своїм населеним пунктом, When відкриває картку, Then зміна недоступна.
   ↑ вигадано: геолокації у вимозі немає

• AC1.1 — нормальний: є опора в AC1, Then можна побачити.
• AC2.1 — AI зробив рівно те, про що йшлося вище: «швидко» перетворив на «2 секунди». Виглядає перевірюваним, але число ніхто не погоджував. Правильний вихід — питання до автора.
• AC5.1 — дві проблеми: Then «коректно обробляє» нічого не каже, а When «натискає» суперечить самій вимозі — за AC5 кнопка в цей момент неактивна.
• AC8 — вигадане правило. Воно звучить розумно, тому око його пропускає, але геолокації у вимозі немає. У відповідях AI такі «розумні доповнення» трапляються часто.

Перш ніж підписатися під AC, перевірте кожен:

1. джерело — пункт вимоги або уточнення;
2. жодного правила чи числа «від себе»;
3. When — одна дія, Then — те, що видно;
4. є негативний і межовий;
5. двоє ставлять однаковий вердикт — той самий тест, з якого почався блок.

Той самий чек-лист варто пройти і на записаній відповіді зі сторінки демо. Два місця, де він спрацьовує:

• Джерело. Нову нумерацію задав сам промпт: старий AC2 став AC3–AC4, старий AC3 розпався на AC5–AC7. Проблема не в нумерації, а в тому, що критерію «джерело» в промпті не було, тож біля нових AC немає посилань на пункти вимоги. Щоб звірити їх з вимогою, відповідність доводиться відновлювати вручну. Саме тому в промпті на слайді 70 є критерій «кожен AC посилається на пункт вимоги».
• Висновок без позначки. В AC11 відповіді є речення «Якщо зміну не виконано (наприклад, оплата не пройшла), профіль не змінюється.» Воно звучить логічно і виведене з AC3 і AC7, але прямо у вимозі цього не сказано, а позначки «припущення» біля нього немає, хоча припущення про лічильник змін у тій самій відповіді позначене. У записаному прогоні пошуку проблем на тій самій сторінці демо AI ставить це як питання: «Чи оновлювати основне відділення, якщо оплата другої зміни не пройшла?» Тож і тут це питання до автора, а не готовий AC.

Повну перевірку згенерованого набору — дублікати, пропуски, вигадки — розібрано в блоці 5 (слайд 81). А наступний блок — про те, як від готових AC перейти до UAT-сценаріїв і тест-кейсів (слайд 74).

4. Від AC до тестових артефактів

Цей блок — про те, як з acceptance criteria отримати те, за чим функцію справді перевіряють. AC каже, що має бути правдою. Тестовий артефакт каже, як саме це перевірити: хто перевіряє, на яких даних і якими кроками. Нижче — чотири артефакти і хто за який відповідає, одне правило у вигляді UAT-сценарію і тест-кейсу поруч, чек-лист і тест-дані, матриця покриття, яка показує, чого бракує, і демо, у якому все це робить AI. Усі приклади взято з демо-вимоги «Зміна адреси доставки» (materials/demo/change-address/requirement.md у репозиторії С2), тож їх можна повторити самостійно.

#Чотири артефакти — чотири питання

Слайди 74 і 75

AC сам нічого не перевіряє. Для перевірки потрібен артефакт: сценарій, за яким бізнес приймає функцію, або тест-кейс, за яким QA шукає відхилення. Для QA це основна робота: за вхідним опитуванням, найчастіша рутина QA — тест-дизайн, тобто тест-кейси з вимог і їх оновлення (7 з 16 відповідей). Для BA UAT-сценарії — це момент, коли бізнес каже «приймаємо» або «ні».

Артефактів чотири, і кожен відповідає на своє питання:

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

Зв'язок між AC і артефактами — «багато до багатьох»: один AC перевіряють кілька тест-кейсів, а один UAT-сценарій проходить через кілька AC. Тому окремо потрібна матриця покриття — про неї нижче. У завданні С2 ролі розподілено так: на рівні L1 BA пише UAT-сценарії, QA — тест-кейси; чек-лист і тест-дані — рівень L2 для QA.

#Одне правило — два погляди

Слайд 76

Той самий фрагмент вимоги — платна друга зміна з AC3 — у двох артефактах. Обидва приклади складено вручну за демо-вимогою; номери UAT-03 і TC-08 умовні.

UAT-сценарій, BA:

UAT-03 · Друга зміна адреси — платна
Передумова: посилка «В дорозі», отримувач уже раз змінював відділення.
Дії: картка посилки → «Змінити адресу» → інше відділення свого міста → оплатити 30 грн → підтвердити.
Очікуваний результат: «Адресу змінено»; у картці — нове відділення й нова дата; кнопка «Змінити адресу» неактивна, під нею текст з AC4.
AC3 · AC4 · AC6 · приймає бізнес

Тест-кейс, QA:

TC-08 · Оплату другої зміни відхилено
Передумови: посилка «В дорозі»; одну зміну вже зроблено; тестова картка, що відхиляє оплату.
Кроки: 1) відкрити картку; 2) «Змінити адресу» → інше відділення того самого населеного пункту; 3) оплатити 30 грн.
Очікуваний результат: у картці — попередня адреса.
Питання: чи рахується невдала спроба як зміна? У вимозі немає → до автора.
AC3 · негативний

UAT-сценарій написано мовою отримувача: «оплатити», «підтвердити», «бачить». Він проходить через три AC одразу: платна зміна (AC3), неактивна кнопка після неї (AC4), повідомлення й нова адреса (AC6). Відповідає він на питання, чи може бізнес прийняти функцію. Сценарій не описує, що відбувається «під капотом», — лише те, що бачить і робить користувач.

Тест-кейс — одна перевірка, один AC і точні передумови: скільки змін уже було, яка картка. Очікуваний результат — рівно те, що каже AC3 («адреса лишається попередньою»), і нічого більше.

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

Якщо коротко, UAT — це мова користувача, шлях від початку до кінця і питання «приймаємо?». Тест-кейс — одна перевірка, точні дані й питання «де відхилення?».

#QA: чек-лист і тест-дані

Слайд 77

Ще два артефакти QA на тій самій вимозі. Чек-лист за AC1–AC4 і розділом «Поза межами»:

- «Прийнята», «В дорозі» — кнопка є · AC1
- Інший статус — кнопки немає · AC1
- Післяплата — кнопки немає · «Поза межами»
- Лише відділення й поштомати того самого населеного пункту · AC2
- Друга зміна — 30 грн до підтвердження · AC3
- Після другої зміни — кнопка неактивна, текст AC4

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

Тест-дані, які треба підготувати:

Кожен рядок — одна межа з частини про AC (слайд 71): статус, лічильник змін, час до дати, оплата. Щоб перевірити межу, потрібна посилка саме в такому стані. Рядок «рівно 24 год» підказує ще одне питання, цього разу до розробки: як на тестовому стенді керувати часом.

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

Отже, тест-дані — це межі з AC, перетворені на конкретні посилки. У завданні С2 чек-лист, тест-дані й перевірка покриття — рівень L2 для QA.

#Матриця покриття: де порожньо

Слайд 78

Матриця покриття показує, чи перевірено все. Рядки — AC, стовпці — три групи з частини про AC (слайд 70): позитивні, негативні, межові. У клітинках — кейси. Приклад для демо-вимоги (номери TC умовні, TC-08 — той самий кейс, що вище):

Читати матрицю треба не за заповненими клітинками, а за порожніми. Позначки означають таке:

• «?» — межа не визначена. Вимога не каже, що має статися, якщо статус змінився, поки отримувач оформлює зміну (AC1), або якщо до дати доставки рівно 24 години (AC5). Тут не пишуть кейс із вигаданим очікуваним результатом — пишуть питання автору.
• «×» — перевіряти нема з чим. В AC2 «швидко» без числа, межі немає. Такий AC повертають на переписування, як у частині про AC.
• «—» — кейсу немає. Або кейс треба дописати, або AC не каже, що має статися. Не кожна порожня клітинка — дефект. Для AC6 порожній негативний означає питання: що бачить отримувач, якщо підтвердження не вдалося? Для AC7 — чи може отримувач відмовитися від того, щоб нове відділення стало основним? Рішення «кейс не потрібен» має бути свідомим.
• Тест без AC — зворотний напрямок. Уявімо, що в наборі є TC-13 «push-сповіщення про нову дату»: у матриці для нього немає рядка. Або його вигадав AI, або у вимозі прогалина. В обох випадках це питання, а не тест.

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

У завданні С2 таблиця «AC → тест-кейси», у якій видно непокриті AC, — рівень L2 для QA. BA на L1 теж вказує AC для кожного UAT-сценарію.

#Демо 2: AC → кейси і матриця покриття

Слайд 79

У демо ту саму роботу доручають AI: промпт QA — у Claude Code, промпт BA — паралельно в чаті в браузері. Мета — побачити, як AC перетворюються на кейси й сценарії і як матриця покриття показує, чого бракує. Результат показують звичайний, не «ідеальний».

Промпт QA — у Claude Code, у новій сесії (/clear):

Роль: ти — QA-інженер; готуєш тестування функції перед релізом.
Вхідні дані: requirement.md у поточній теці — AC1–AC7 і «Поза межами». Працюй лише з цим файлом, інших файлів не відкривай.
Задача: склади тест-кейси до AC1–AC7 і перевір, які AC ними покрито.
Критерії приймання:
- щонайменше шість кейсів, серед них негативні й межові (час, кількість змін, статус);
- кожен кейс посилається на AC;
- очікуваний результат — лише з вимоги; якщо вимога мовчить — не вгадуй, винеси в «Питання».
Формат: таблиця «ID · назва · передумови · кроки · очікуваний результат · тип · AC»; далі матриця «AC · позитивні · негативні · межові», порожні клітинки — «—»; далі «Питання».

Claude Code запускають в окремій теці, де лежить лише копія requirement.md. Агент бачить усе, що є в теці, тому фраза «інших файлів не відкривай» — друга лінія захисту, а не перша.

Промпт BA — той самий, але в ньому замінено три рядки: роль, задачу і перший критерій. Для чату замінено й рядок вхідних даних, а під промптом між рядками === вставлено повний текст requirement.md:

Роль: ти — бізнес-аналітик; готуєш приймання функції разом із бізнесом.
Вхідні дані: вимога «Зміна адреси доставки» між === нижче — AC1–AC7 і «Поза межами». Працюй лише з нею.
Задача: склади UAT-сценарії мовою отримувача до AC1–AC7 і перевір, які AC ними покрито.
Критерії приймання:
- щонайменше чотири сценарії, серед них щонайменше два негативні;
- кожен кейс посилається на AC;
- очікуваний результат — лише з вимоги; якщо вимога мовчить — не вгадуй, винеси в «Питання».
Формат: таблиця «ID · назва · передумови · кроки · очікуваний результат · тип · AC»; далі матриця «AC · позитивні · негативні · межові», порожні клітинки — «—»; далі «Питання».
===
[повний текст requirement.md]
===

«Щонайменше два негативні» — планка сильної роботи; для L1 у завданні досить одного негативного сценарію. Промпт QA теж можна запустити в чаті — так само з текстом вимоги між ===.

Як читати відповідь. Шукаємо три речі: AC без кейсу, кейс без AC і межу без рішення.

1. У відповіді QA почати з матриці, а не з таблиці кейсів: які клітинки порожні? Потім один-два кейси звірити з requirement.md — на який AC посилається кейс і чи є його очікуваний результат у вимозі — і пошукати кейси без AC.
2. У відповіді BA: чи це справді мова отримувача, а не «система перевіряє»; скільки негативних сценаріїв; які AC покрито — порівняти з матрицею QA.
3. У «Питаннях» обох відповідей для кожного питання назвати, з якого AC воно виникло.

У сильній відповіді QA є статуси «Прийнята», «В дорозі» й інший; перша, друга й третя спроба з текстом AC4; успішна й неуспішна оплата другої зміни; відділення й поштомат у тому самому та в іншому населеному пункті; трохи більше, рівно і трохи менше 24 годин для AC5; основне відділення після зміни (AC7); посилка з післяплатою. У сильній відповіді BA — перша безкоштовна зміна, платна друга, вичерпаний ліміт, пізня спроба (AC5), неуспішна оплата, зміна на поштомат, серед них щонайменше два негативні. Типові вигадки: SMS чи push про нову адресу, скасування зміни з поверненням 30 грн, геолокація, обмеження за часом доби, зміна отримувача як частина функції (у вимозі вона винесена в «Поза межами»), правила зі старої специфікації С1 («протягом 15 хвилин», «вантажні відділення» й 30 кг, «будь-яке відділення в Україні», «ще 2 рази»). Таких правил у вимозі версії 1.0 немає; детально вигадки розбирає частина 5.

Що AI видав у записаному прогоні. На сторінці демо є запис QA-прогону (Claude Code, модель Claude Sonnet, 26.09.2026) з трохи іншим промптом: роль «досвідчений тест-дизайнер», текст вимоги вставлено в сам промпт між ===, щонайменше вісім кейсів, окрема колонка «Тест-дані», матриця «AC → ID кейсів» і список прогалин. Результат:

• 18 тест-кейсів за 56 секунд: 8 позитивних, 5 негативних, 5 межових. Усе з переліку для QA вище є, зокрема 24 год 01 хв, рівно 24:00 і 23:59 до доставки (TC-11–TC-13).
• Де вимога мовчить, AI не вгадував. У кейсі про відхилену оплату (TC-08): «Текст помилки й чи зараховується спроба у ліміт — потребує уточнення». Для рівно 24:00 кнопка активна «за буквою AC», з приміткою «підтвердити з автором».
• У списку з 13 прогалин і неоднозначностей — «зручно» і «швидко» без вимірних критеріїв (AC2 покрито лише частково), відлік 24 годин і часовий пояс, суперечність «на сайті» в AC1 з розділом «Поза межами», перетин AC4 і AC5. Кейс про післяплату AI сам позначив як кейс без AC: «окремого AC немає».
• Кейс «Профіль не змінюється, якщо платна зміна не відбулася» (TC-17, AC3 і AC7) AI вивів з AC3, сам приписав «підтвердити» і виніс те саме в список прогалин (пункт 8) — це кандидат у питання автору, а не готова перевірка. Скасування вибору й повернення 30 грн у разі невдалої зміни AI не перетворив на кейси, а виніс у прогалини як те, чого немає в AC, — «щоб не вигадувати поведінку».
• Чого немає: негативного кейсу для AC6 і питання, що буде, якщо статус посилки змінився, поки отримувач оформлює зміну.

У записі BA промпт просив ще й переписати AC, тож AC там перенумеровано (AC1–AC11). UAT-сценаріїв дев'ять, з них три негативні й два межові. Сценарій про пошук і зручність списку AI позначив як неготовий, доки автор не задасть число секунд і критерії зручності. Що невдала оплата не збільшує лічильник змін, AI записав як припущення для підтвердження автором — це те саме питання, що в TC-08 вище.

Якщо відповідь задовга або всі клітинки матриці підозріло заповнені, допомагають два уточнення:

Покажи лише матрицю покриття і «Питання».

Для кожного очікуваного результату процитуй AC, на якому він ґрунтується.

Кейси без цитати — кандидати у вигадки. Обидві відповіді варто зберегти: у частині 5 (слайд 81) їх розбирають на дублікати, пропуски й вигадки. Повний записаний прогін — на сторінці демо С2, промпти для кожного кроку завдання — у шпаргалці С2.

#Ланцюжок, який можна перевірити

Слайд 80

Уся середина заняття — один ланцюжок:

1. Вимога — проблеми й питання (частина 2).
2. AC — Given/When/Then, три групи (частина 3).
3. Артефакти — UAT-сценарії для BA, тест-кейси й тест-дані для QA.
4. Матриця — AC → кейси, порожні клітинки.
5. Питання — автору, замість здогадки.

Кожна ланка посилається на попередню: кейс — на AC, AC — на пункт вимоги або на відповідь автора. Там, де посилання немає, — або пропущений тест, або вигадка, або прогалина у вимозі.

Той самий ланцюжок — це завдання С2 на вашому варіанті. Його ланки — розділи 2–6 звіту, рівень L1. Матриця покриття «AC → тест-кейси» — рівень L2 для QA, розділ 7 звіту. Детально про завдання — у частині 7 (слайд 91). А як переконатися, що набір перевіряє саме вимогу — всю, без повторів і без вигадок, — тема наступної частини.

5. Перевірка згенерованого

Цей блок — про те, як перевірити не окреме твердження AI, а цілий згенерований набір: AC, UAT-сценарії, тест-кейси. У С1 ми звіряли кожне твердження з джерелом і ставили один із чотирьох вердиктів. Тут питання ширше: чи набір як ціле перевіряє вимогу — всю, без повторів і без вигадок. Нижче — чотири питання до будь-якого згенерованого набору, приклад того, що видно лише поруч із вимогою, прийоми, якими AI допомагає звузити пошук, і як записати результат перевірки в розділ 6 звіту С2.

#Багато тест-кейсів — ще не покриття

Слайд 81

AI генерує швидко й багато. Ваша робота — переконатися, що згенероване перевіряє саме вимогу: всю, без повторів і без вигадок.

У С1 ми перевіряли окремі твердження: кожне отримувало вердикт «вірно», «вигадано», «пропущено» або «проблема в матеріалі», і кожен вердикт доводився пунктом джерела (слайд 28). Тепер у нас цілий набір артефактів, і питання не лише «чи правдивий кожен рядок», а «чи набір як ціле перевіряє вимогу».

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

Це й ваша щоденна робота: у вхідному опитуванні BA окремо згадували рев'ю вимог і задач, зокрема згенерованих AI. Одна з цитат — «вичитка великих об'ємних BRD, згенерованих бізнесом через AI».

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

#Чотири питання до згенерованого набору

Слайд 82

Приклади — з демо-вимоги «Зміна адреси доставки», версія 1.0 (requirement.md), яку розбирали в демо 1 і демо 2.

1. Повнота. На це питання відповідає матриця покриття з попереднього блоку (слайд 78): AC → кейси. Але рахувати треба не AC, а гілки. AC3 — одна фраза і три різні поведінки: безкоштовна перша зміна, платна друга і неуспішна оплата («адреса лишається попередньою»). Один кейс на AC3 — це не покриття AC3.

2. Дублікати. AI любить переказувати той самий кейс іншими словами. Дублікати роздувають набір і створюють враження повноти, а за ними ховаються пропуски.

3. Межові й негативні. Модель тяжіє до позитивного сценарію. На демо-вимозі варто шукати третю спробу після двох змін (текст AC4), статус, у якому кнопки немає (AC1), і межу AC5. Для AC5 — важливе застереження: «менш ніж за 24 години до очікуваної дати доставки», а в дати немає часу. Від 00:00? Від початку роботи відділення? Рівно 24 години — ще можна? Тож межові кейси (трохи більше, рівно і трохи менше 24 годин) пишуть з позначкою «межу треба уточнити» і питанням до автора, а не з упевненим очікуваним результатом.

4. Вигадки. Вони мають два джерела. Перше — «звичайна практика»: SMS про нову адресу, скасування зміни з поверненням 30 грн. У вимозі цього немає. Друге — старий контекст. У С1 демо-варіант був про цю саму функцію, і якщо працювати в тому самому чаті, модель охоче повертає правила зі старої специфікації: «нова дата протягом 15 хвилин», «вантажні відділення понад 30 кг», «ще 2 рази». У версії 1.0 нічого з цього немає. Ліки — правило з С1: нова задача — нова сесія.

#Що видно лише поруч із вимогою

Слайд 83

Ліворуч на слайді — фрагмент демо-вимоги, скорочено:

AC3. Не більше двох змін. Перша — безкоштовна, друга — 30 грн, оплата карткою до підтвердження. Якщо оплата не пройшла, адреса лишається попередньою.
AC4. Після другої зміни кнопка неактивна, текст «Ви вже змінили адресу максимальну кількість разів.»
AC5. Зміна недоступна менш ніж за 24 години до очікуваної дати доставки.

Праворуч — тест-кейси AI. Це ілюстрація, складена з типових помилок, а не запис конкретної сесії:

TC1. Перша зміна — без оплати, «Адресу змінено» · AC3
TC2. Друга зміна — оплата 30 грн карткою · AC3
TC3. Зміна вперше — оплата не запитується · AC3
   ↑ дублікат TC1: та сама гілка AC3
TC4. Після зміни отримувач отримує SMS з новою адресою
   ↑ вигадано: сповіщень у вимозі немає
TC5. Після другої зміни кнопка неактивна, текст AC4 · AC4
✗ пропущено: оплата не пройшла (AC3) · інший статус — кнопки немає (AC1) · межа 24 год (AC5)

Праву колонку читають згори донизу, щоразу дивлячись у ліву:

• TC1, TC2 — нормальні кейси з посиланням на AC.
• TC3 — той самий TC1 іншими словами. Кейсів на AC3 три, а гілок перевірено дві.
• TC4 — вигадка. Звучить як «звичайна практика», тому око її пропускає, але сповіщень у вимозі немає.
• TC5 — нормальний: це і є перевірка третьої спроби за AC4.
• Останній рядок — найважливіший і найнепомітніший: пропущене. Неуспішна оплата (третя гілка AC3), посилка в іншому статусі, де кнопки немає (негативна гілка AC1), межа AC5. AC2 і AC7 у цьому наборі теж без жодного кейсу.

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

Чотири питання на справжній відповіді. На сторінці демо С2 записано відповідь на QA-промпт (Claude Code, модель Claude Sonnet, 26.09): 18 тест-кейсів TC-01…TC-18, матриця покриття і 13 пунктів прогалин. Що вона містить, детально розібрано в частині 4 (слайд 79); тут — лише як на неї відповідають чотири питання.

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

#Хай AI звузить пошук

Слайд 84

Це продовження прийомів із С1 (слайд 29), тільки для набору артефактів, а не для окремих тверджень.

1. Кожен кейс — з AC. Кейс без AC — кандидат у вигадки, AC без кейсу — пропуск. Одна фраза в критеріях приймання промпту дає ту саму матрицю покриття, що в блоці 4 (слайд 78).

Для кожного кейсу вкажи AC. Окремо: AC без кейсів і кейси без AC.

2. Позначка типу. Коли кожен кейс позначено, нуль негативних чи межових видно одразу, без читання.

Познач кожен кейс: позитивний / негативний / межовий.

3. Рецензент у новій сесії. Рецензент бачить лише вимогу і набір — без історії генерації. Окрема сесія потрібна, щоб він не підхоплював аргументів першої відповіді і не тягнув правил зі старої версії документа, яка могла лишитися в розмові.

Ось вимога і тест-кейси. Знайди дублікати, кейси без опори у вимозі й гілки AC без кейсу.

Повніший варіант того самого прийому для агента, який читає вимогу з файлу. Перед ним — /clear або нова розмова, а тест-кейси вставляють між рядками ===:

Вхідні дані: materials/demo/change-address/requirement.md і тест-кейси нижче між ===. Працюй лише з ними, інші теки не відкривай.
Задача: знайди дублікати, кейси без опори у вимозі і гілки AC без жодного кейсу.
Формат: таблиця «кейс або AC · проблема · що зробити».

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

4. Вигадка чи знахідка? Найтонше місце. Якщо AI написав кейс «статус змінився під час оплати → гроші повертаються автоматично», то сама ситуація — цінна знахідка, ваше «а що якщо», а очікуваний результат — вигадка: вимога цього не описує. Правильний хід — не видаляти кейс, а перетворити його на питання до автора вимоги. На демо-вимозі це питання до AC3 і AC6: статус змінився під час оплати — що з 30 грн? Ту саму прогалину видно в баг-репорті демо-варіанту (слайд 88).

Усі прийоми лише звужують пошук. Вердикт ставите ви — відкривши AC.

#Результат перевірки — розділ 6 звіту

Слайд 85

Перевірка згенерованого — частина L1 у С2. У шаблоні звіту templates/c2-report.md це розділ 6: що ви змінили у відповіді AI і чому — дублікати, вигадки (правила, яких немає у вимозі), пропущені межові й негативні випадки, AC без жодного сценарію. Розділ заповнюють таблицею з трьох колонок: що було у відповіді AI, що ви зробили, чому. Рядки нижче — з ілюстрації двома слайдами раніше.

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

Зверніть увагу на рядок 4: він закінчується не виправленням, а питанням до автора. Це нормальний і цінний результат перевірки.

Перед здачею зручно пройти чек-лист зі шпаргалки С2:

[ ] кожна проблема — з місцем і цитатою з вимоги мого варіанту
[ ] у відповіді немає правил, чисел і строків, яких немає у вимозі
[ ] кожен AC перевірюваний і має хоча б один сценарій чи кейс
[ ] є негативні й межові сценарії
[ ] немає дублікатів
[ ] у звіті видно, що саме я виправив у відповіді AI

Кожен пункт має бути відмічено — або в розділі 6 пояснено, чому ні.

Такі прогалини у вимозі часто вперше помічає не аналітик, а тестувальник — через баг-репорт. Про це наступний блок (слайд 86).

6. Баг-репорт

Цей блок — про баг-репорт як місце, де зустрічаються QA і BA. QA фіксує, що сталося, BA вирішує, що мало статися, а зустрічаються вони у зв'язку з вимогою. Спершу розберемо, з яких частин складається репорт і як кожну з них читає кожна роль. Потім — демо-репорт: це дефект коду чи прогалина вимоги, чого бракує в самому репорті і що змінити у вимозі. Для BA це рівень L2 завдання С2, розділ 7 звіту.

#Баг-репорт — спільна мова QA і BA

Слайд 86

Баг-репорт зазвичай вважають документом QA для розробника. Але найцікавіші репорти — ті, після яких з'ясовується, що код робить саме те, що написано, а написано не все. Тоді це вже питання до BA.

Далі йдеться про чотири частини репорту: кроки, очікуване й фактичне, ймовірну причину і зв'язок з вимогою.

Згадайте цитату QA з вхідного опитування: «аналіз вимог у задачі, пошук кейсів, які можуть бути не покриті вимогами». Баг-репорт — місце, де такий непокритий кейс уперше стає видимим.

#Один документ — два читачі

Слайд 87

Середня колонка — як пише QA, права — що з того самого рядка бере BA.

• Кроки. Без номера посилки, акаунта, версії й умов репорт повертається з питаннями. Для BA кроки — це сценарій користувача: у якому стані була посилка і що робила людина.
• Очікуване. Сильний репорт посилається на AC. Тоді BA одразу бачить друге питання: а чи описує цей AC саме таку ситуацію? Якщо ні, очікуване в репорті придумав тестувальник, хай і розумно.
• Фактичне. Точний текст помилки, стан, час. BA перекладає це на вплив: що втрачає отримувач і скільки це коштує бізнесу.
• Ймовірна причина. QA дає гіпотезу, а BA вирішує головне: це дефект коду чи прогалина вимоги. Від цього залежить, хто виправляє — розробник чи автор вимоги.
• Зв'язок з вимогою — місце, де QA і BA говорять однією мовою: номер AC.

Три правила внизу слайда:

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

#Демо: дефект коду чи прогалина вимоги?

Слайд 88

Демо-репорт — файл materials/demo/change-address/bug-report.md у репозиторії практики gitlab.com/koldovsky/ai-qa-ba-c2. Він написаний до тієї самої вимоги «Зміна адреси доставки» з блоку про вимоги. На слайді репорт скорочено, повний текст такий:

Баг-репорт: адреса не змінюється після підтвердження
Середовище: застосунок «Пакунок», Android, тестовий стенд.
Кроки:
1. Відкрити картку посилки зі статусом «В дорозі».
2. Натиснути «Змінити адресу», обрати інше відділення.
3. Натиснути «Підтвердити».
Очікуваний результат: повідомлення «Адресу змінено», у картці посилки — нова адреса (AC6).
Фактичний результат: помилка «Щось пішло не так», адреса стара. Зараз у картці статус «Прибула у відділення», його встановлено о 14:02 — я підтверджувала зміну приблизно тоді ж. Ще: у списку поштоматів є поштомати сусіднього міста.
Серйозність: критична.
Коментар: відтворюється не завжди, на інших посилках зміна проходила.

Промпт зі слайда:

Роль: ти — бізнес-аналітик; розбираєш баг-репорт від QA.
Вхідні дані: bug-report.md і requirement.md
з теки materials/demo/change-address/.
Працюй лише з ними, інші теки не відкривай.
Задача: для кожної проблеми з репорту визнач тип —
дефект коду, прогалина у вимозі чи бракує даних.
Критерії приймання:
- кожен висновок посилається на AC або розділ вимоги;
- вимога не описує ситуацію — так і скажи, не вигадуй;
- окремо: яких даних бракує для відтворення.
Формат: таблиця «проблема · тип · AC · чому · що робити»;
під нею — «Питання до авторки» і «Що змінити у вимозі».

Промпт розрахований на агента (Claude Code) у новій сесії (/clear), запущеного в окремій теці, де лежить лише materials/demo/change-address/ з обома файлами. Рядок «інші теки не відкривай» тримає агента в межах двох файлів. У чаті замість шляхів вставте обидва файли між рядками ===.

Мета демо — показати саму класифікацію, а не отримати ідеальну таблицю. Кожен рядок відповіді перевіряють так: відкривають названий AC у requirement.md і звіряють. Вердикти ті самі чотири, що в С1: вірно, вигадано, пропущено, проблема в матеріалі. Дві типові пастки:

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

Що AI видав у записаному прогоні. Прогін записано 26.09.2026 у Claude Code (модель Claude Sonnet), відповідь прийшла за 46 секунд. Промпт — варіант для BA L2 зі шпаргалки С2 з близькими критеріями: дефект коду чи прогалина, чого бракує в репорті, що змінити у вимозі. На відміну від слайда, він окремо питає, чи не змішано в одному репорті кілька проблем. Обидва файли в ньому вставлено між рядками ===. Формат — не таблиця з двома списками, а чотири розділи: «Класифікація», «Зв'язок з вимогою», «Чого бракує в репорті» і «Пропозиція до вимоги».

• Класифікація. Три пункти. Помилка під час підтвердження — імовірно, прогалина вимоги, а дефект коду не доведений. Поштомати сусіднього міста — дефект коду проти AC2, за умови, що початкова адреса справді в іншому населеному пункті. «Відтворюється не завжди» — не окрема проблема, а ознака гонки станів або нестабільних даних. Висновок AI: у репорті дві різні проблеми, його треба розділити на два.
• Зв'язок з вимогою. Посилання на AC6 AI вважає некоректним: AC6 описує успішний сценарій, а в статусі «Прибула у відділення» зміна за AC1 не дозволена. При цьому AC1 описує лише видимість кнопки на вході в сценарій, а не перевірку під час підтвердження. Текст помилки вимога не описує, тож «Щось пішло не так» формально не порушує жодного AC. Дефектом коду це стане, лише якщо журнал статусів покаже, що в момент підтвердження посилка ще була «В дорозі». Окремо AI згадав можливе порушення AC5, яке без очікуваної дати доставки не перевірити.
• Чого бракує в репорті. Точний час натискання «Підтвердити» й історія статусів з часовими мітками. Номер посилки, початкова адреса й очікувана дата доставки. Скільки змін уже було: якщо це друга, у кроках бракує етапу оплати, якого вимагає AC3. Чи стягнули гроші. Ознака післяплати. Які саме поштомати. У скількох спробах відтворюється. Версія застосунку й Android, акаунт, журнал запиту. Серйозність «критична», на думку AI, без даних про частоту не обґрунтована.
• Пропозиція до вимоги. Шість пунктів. Перші три — нові AC: перевірка на момент підтвердження з текстом «Посилка вже прибула у відділення, змінити адресу неможливо»; що з грошима, якщо зміну не застосовано; зрозуміле повідомлення про технічну помилку замість «Щось пішло не так». Інші три — уточнити AC5, уточнити AC2 і прибрати суперечність між AC1 і «Поза межами».

Порівняно з розбором на наступному слайді відповідь збігається в головному: основна проблема — найімовірніше, прогалина вимоги, поштомати — окремий ймовірний дефект, даних бракує. Різниця — у «Щось пішло не так»: розбір допускає тут дефект коду, а AI його так не називає. Тексту помилки не описує жоден AC, тож AI пропонує новий AC, а не фікс коду. Обидва погляди сходяться в тому, що загальний текст треба замінити. Пункти 4–6 пропозиції здебільшого повторюють знахідки рев'ю вимоги з демо 1: межа AC5, «зручно» і «швидко», сайт.

Повна відповідь — на сторінці демо С2.

#Один репорт — три різні речі

Слайд 89

Це розбір демо-репорту, який мав вийти. У ньому три окремі речі.

1. Найімовірніше — прогалина вимоги. Зміну підтверджували приблизно тоді ж, коли посилка отримала статус «Прибула у відділення». Після цього статусу зміна за AC1 недоступна, тож код, найімовірніше, зробив те, що дозволяє AC1. Але вимога не каже, що має статися, коли статус змінюється, поки людина оформлює зміну: що вона бачить, чи зміну застосовано, що з оплатою (AC1, AC6). Це те саме «а що якщо» в потоці AC1, AC3, AC6 — стан змінюється посеред дії (слайд 63). Дефектом коду тут може бути хіба що загальне «Щось пішло не так» замість зрозумілого пояснення. Висновок умовний: його перевіряє точний час натискання «Підтвердити» щодо 14:02.

2. Ймовірний дефект коду. У списку — поштомати сусіднього міста, а AC2 прямо обмежує вибір відділеннями й поштоматами того самого населеного пункту. Це зовсім інша проблема, і на неї потрібен окремий тікет зі своїми кроками. Коли в одному тікеті два симптоми, один із них загубиться.

3. Бракує даних:

• номер посилки й акаунт;
• очікувана дата доставки (AC5);
• перша чи друга, платна зміна;
• точний час підтвердження;
• версія застосунку і пристрій;
• за яких умов «не завжди».

Без цього репорт не відтворити і не оцінити, і жодна класифікація не остаточна. Особливо важливі дві речі. Перша — котра це зміна: перша чи друга, платна. Друга — очікувана дата доставки: якщо посилка прибула того ж чи наступного дня, за AC5 кнопка мала бути неактивною ще до 14:02, і це вже зовсім інший репорт.

#Мовою аналітика: що змінити і кого спитати

Слайд 90

Розбір аналітика закінчується не вердиктом, а трьома діями.

1. Зміна вимоги. Для ситуації, якої бракувало, пишуть новий AC у форматі Given/When/Then з блоку про acceptance criteria. Це пропозиція, формулювання треба узгодити:

AC8 (новий). Given отримувач оформлює зміну адреси, а посилка тим часом отримала статус «Прибула у відділення»,
When він натискає «Підтвердити»,
Then зміну не застосовано, замість «Щось пішло не так» він бачить текст «Посилка вже у відділенні — змінити адресу не можна.», а оплату за зміну не списано або повернено.

Текст повідомлення тут конкретний, щоб AC можна було перевірити. Але остаточне формулювання і рішення щодо оплати («не списано» чи «повернено») узгоджує власник продукту. Номер AC8 умовний — просто наступний після AC7. З вигаданим AC8 про геолокацію з блоку про acceptance criteria (слайд 73) він не пов'язаний.

2. Окремий тікет на дефект. Поштомати сусіднього міста у списку. Очікуване — AC2: лише той самий населений пункт. У тікеті свої кроки й посилання на AC2.

3. Питання до авторки репорту — про дані, яких бракувало:

• Номер посилки й акаунт?
• Очікувана дата доставки?
• Перша чи друга зміна — чи списано 30 грн?
• Точний час підтвердження щодо 14:02?
• Версія застосунку, пристрій?

Серйозність «критична» варто переоцінити після відповідей. Зміна після прибуття у відділення за AC1 і так недоступна. Найгірший випадок — 30 грн списано, а зміни немає, але з репорту цього не видно. Мовою аналітика це вплив: отримувач не розуміє, що сталося, і дзвонить у контакт-центр. А версія 1.0 якраз мала прибрати ці дзвінки (розділ «Контекст» вимоги).

Для BA на рівні L2 завдання С2 потрібен саме такий розбір bug-report.md свого варіанту: дефект коду чи прогалина вимоги, до якого AC належить, що змінити у вимозі. Це розділ 7 шаблону звіту templates/c2-report.md, а промпт для розбору є в шпаргалці С2. Далі — саме завдання С2 (слайд 91).

7. Завдання С2

Цей блок — про практичне завдання другого заняття. Це та сама робота, яку на занятті показували наживо на демо-вимозі «Зміна адреси доставки», тільки на вашій функції: знайти проблеми у вимозі, поставити питання й переписати AC, зробити тестові артефакти за своєю роллю і перевірити згенероване. Нижче — що саме зробити, що входить у рівні L1–L3, як заповнити звіт, як здати роботу через браузер, яких помилок С1 не повторювати і що буде після строку.

#Завдання С2: та сама функція — новий документ

Слайд 91

Вимога версії 1.0 вашої функції сервісу «Пакунок» уже пішла в розробку. Знайдіть, що в ній не так, — раніше, ніж це знайде розробка.

Функція та сама, що в С1, а документ новий — вимога версії 1.0. Проблеми в ній теж нові, тож знахідки з С1 сюди не переносяться.

Завдання складається з чотирьох кроків — це чотири блоки заняття:

Останній крок на слайді підсвічено: без показаної перевірки L1 не зараховується.

Варіант — той самий номер, що в С1, за першою літерою прізвища. Хто приєднався пізніше, знайде себе в таблиці «Ваш варіант» у README репозиторію С2:

У кожного варіанту три файли: requirement.md — для L1, усім; bug-report.md — для L2 у BA; sources.md — для L3.

Ще три умови:

• підходить будь-який AI-інструмент, звичайний чат у браузері теж;
• токен-звіту в С2 немає — на відміну від С1;
• демо-варіант, як і в С1, не зараховується.

#L1 обов'язковий, L2 і L3 — зверху

Слайд 92

Перший рядок спільний для BA і QA: щонайменше дві проблеми у вимозі, щонайменше три уточнювальні питання, переписані AC (серед них щонайменше один негативний чи межовий), перевірка того, що згенерував AI, і висновок своїми словами. Другий і третій рядки — за роллю: BA додає чотири UAT-сценарії, серед них негативний; QA — шість тест-кейсів з кроками й очікуваним результатом, серед них межовий і негативний. Кожен сценарій чи тест-кейс — з номером AC, який він перевіряє. L1, як і в С1, зараховується як «виконано / не виконано»: є всі частини — 10 балів.

L2 — продовження демо 2 і частини про баг-репорт. BA на L2 розбиває сторі за INVEST і розбирає баг-репорт свого варіанту: це дефект коду чи прогалина у вимозі (слайд 88). QA на L2 робить чек-лист, тест-дані й таблицю покриття, у якій видно AC без жодного тест-кейсу (слайди 77 і 78).

L3 — нове порівняно з С1: кілька джерел, які суперечать одне одному і вимозі. Тут потрібне не «уточнити в замовника», а власне рішення з обґрунтуванням і відкриті питання — кому і що спитати.

L2 і L3 — за бажанням. Роль одна, своя: робити і BA, і QA не треба. Робота за чужим або демо-варіантом не зараховується.

#Шаблон c2-report.md: шість розділів L1

Слайд 93

Шаблон звіту — templates/c2-report.md у репозиторії С2. Він повторює кроки завдання: розділи 1–6 — це L1, у тому самому порядку, у якому йшло заняття.

Три речі, на які варто звернути увагу:

• Розділ 1. Відповідь AI — повністю. Якщо вона дуже довга, можна вставити перші 80 рядків з приміткою «скорочено», але так, щоб не зникли саме ті питання і прогалини, які ви потім перевіряєте.
• Розділ 2. Колонка «Хто знайшов»: ви, AI чи обидва. Чесна відповідь «AI» — нормальна; цікаво, що ви знайшли понад AI.
• Розділ 6. Не «AI все зробив правильно», а що саме ви прибрали, виправили чи додали — і чому. Як це записати, показано в частині 5 (слайд 85).

Шапка — як у С1: прізвище та ім'я, варіант, роль і виконані рівні. У шаблоні вона така (підказки «← …» після кожного рядка тут прибрано — у звіті їх теж треба прибрати):

**Прізвище та ім'я:** Прізвище Ім'я
**Варіант:** NN
**Роль:** QA / BA
**Виконані рівні:** L1 · L2 · L3

У рядку ролі залиште одну роль, у рядку рівнів — лише ті, що виконали. Нове порівняно з С1: промпт і відповідь AI — в одному розділі, далі йдуть розділи 2–5 під блоки цього заняття, у розділі 2 з'явилася колонка «Хто знайшов», а розділів про токени немає. Розділ 9, висновок, обов'язковий навіть без L2 і L3.

#Здача — новий проєкт і новий форк

Слайд 94

Здають так само, як у С1: merge request на gitlab.com, лише браузер, git не потрібен. Відмінностей дві — новий проєкт і новий форк.

Крок 0 приховує вашу пошту в комітах; якщо ви зробили його в С1, повторювати не треба. У назві файлу замість <username> — ваш username на gitlab.com, а косі риски самі створять теки. New file натискайте на головній сторінці копії і перед збереженням перечитайте повний шлях у полі назви: саме на цьому кроці в С1 файли потрапляли в templates/submissions/…. У рядку «Прізвище та ім'я» лишіть дві пари зірочок і допишіть свої прізвище та ім'я.

На занятті тренер проходить цей шлях один раз на демо-варіанті: варіант у звіті — «демо», merge request — «С2 · koldovsky · демо». У формі Fork тренер змінює назву і slug копії на ai-qa-ba-c2-demo лише тому, що проєкт належить йому. Вам нічого перейменовувати не треба: форк лишається з початковою назвою у вашому namespace.

Виправити щось до строку можна в тому самому merge request: відредагуйте файл у гілці c2 своєї копії, і merge request оновиться сам. Новий MR не потрібен.

Репозиторій gitlab.com/koldovsky/ai-qa-ba-c2 містить варіанти, шаблон звіту і ці самі кроки здачі в README. Що вписати на кожному кроці GitLab — також у шпаргалці С2, а як виконати завдання від початку до кінця на демо-варіанті, з реальними відповідями AI, — на сторінці демо С2.

#Помилки здачі С1 — перевірте перед здачею

Слайд 95

Скільки робіт мали кожну з цих помилок, тренер показав на розборі С1 на початку заняття. Тут — як їх уникнути.

Жодна з цих помилок не про знання — усі про неуважність за хвилину до здачі. А ціна висока: файл у неправильній теці чи з пробілом у назві скрипт перевірки просто не знайде, і робота виглядатиме як нездана.

1. New file натискайте на головній сторінці своєї копії, а не всередині теки templates, — інакше шлях почнеться з templates/.
2. Шлях краще скопіювати з README, ніж набирати: одна пропущена літера чи пробіл у кінці — і файл «зник».
3. Форк — лише з оригінального проєкту. Якщо зробити форк із копії колеги, у ваш MR потрапить його файл.
4. Вкладка Changes у MR — остання перевірка: там один файл, ваш, у submissions/.
5. Рядок з прізвищем та ім'ям лишайте з двома парами зірочок і замініть лише «Прізвище Ім'я»: за цим рядком зараховуються бали.

І три речі з перевірки змісту С1, які стосуються шаблону С2: не обрізайте відповідь AI саме там, де питання і прогалини; приберіть підказки зі стрілками «← …», які залишилися з шаблону; не лишайте висновок порожнім.

#Строк — вівторок, 06.10, розбір — на С3

Слайд 96

На завдання — шість днів. Строк не переноситься: розбір має сенс, поки тема свіжа. Так само і з усіма завданнями курсу: строк — 23:59 вівторка напередодні наступного заняття, розбір — на ньому.

Після строку все відбувається так само, як у С1:

• 7 жовтня, до заняття, кожен merge request перевіряє AI-рев'юер за рубрикою, частину робіт тренер переглядає сам;
• відгук — коментар у вашому MR з порадами, без балів; бали йдуть у рейтинг курсу;
• якщо ви не згодні з відгуком, напишіть коментар у своєму MR — тренер розгляне його особисто;
• до строку виправляти можна скільки завгодно, у тому самому MR.

Репозиторій публічний, як і в С1: лише матеріали курсу, без корпоративних даних, паролів та імен колег. Прізвище та ім'я у звіті бачать усі.

Питання щодо завдання — у Telegram-чат когорти, гілки QA і BA.

8. До С3

Цей блок — завершення заняття: що зробити до С3, п'ять головних думок С2, де шукати матеріали і короткі відповіді на типові питання про завдання. Одну дію з нього варто виконати ще цього тижня, не чекаючи строку: переконатися, що агентне середовище запускається на вашому комп'ютері. Завдання С2 від цього не залежить, а С3 — залежить.

#До С3: агентне середовище — уже цього тижня

Слайд 97

З С3 курс переходить від чату до агента, який сам працює з трекером і базою знань через MCP. Тому на С3 працюємо саме в агенті, і без робочого середовища на цьому занятті можна буде лише дивитися. Середовище з вступного пакета має запускатися на вашому комп'ютері до 07.10.

Звідси одна дія на цей тиждень: запустити агент із вступного пакета і переконатися, що він працює.

Завдання С2 від агента не залежить. Його можна виконати в будь-якому AI-інструменті — чат у браузері теж підходить.

Що буде на С3, 7 жовтня: агент, трекер і база знань. Те, що на С2 ви робили вручну з вимогою, агент робитиме із задачею в трекері.

#П'ять речей, які забираєте

Слайд 98

Кожен пункт — один блок заняття, і кожен перевіряється в завданні С2. Якщо якась думка здається неочевидною, поверніться до слайдів її блоку.

Перші чотири пункти — це кроки L1 у тому самому порядку, в якому йде заняття: знайти проблеми й поставити питання, переписати AC, побудувати з них тестові артефакти з посиланням на AC і перевірити, що згенерував AI. Окрема матриця покриття AC тест-кейсами — завдання L2 для QA. П'ятий пункт — продовження для BA на рівні L2.

Цей слайд варто зберегти й перечитати перед тим, як сідати за завдання.

#Ресурси

Слайд 99

Усе, що потрібно після заняття, зібрано за трьома посиланнями.

З сайту курсу ведуть дві сторінки, які знадобляться для завдання:

• Демо С2 — завдання на демо-варіанті «Зміна адреси доставки» з записаними відповідями AI: проблеми у вимозі й уточнювальні питання, AC і UAT-сценарії (BA), тест-кейси й перевірка покриття (QA), перевірка згенерованого, розбір баг-репорту (L2 BA) і здача;
• Шпаргалка С2 — промпти для кожного кроку завдання, чек-лист перевірки перед здачею і що вписати на кроках GitLab.

Зручний порядок роботи над завданням:

1. Відкрити requirement.md свого варіанту — номер той самий, що в С1, таблиця в README репозиторію.
2. Подивитися на сторінці демо, як виглядає весь шлях на демо-вимозі.
3. Взяти промпти зі шпаргалки: спершу проблеми і питання, потім AC і UAT-сценарії (BA) або тест-кейси й покриття (QA).
4. Звірити відповіді з вимогою і заповнити розділ 6 звіту: що ви змінили і чому.
5. Здати merge request до вівторка, 06.10, 23:59.

Головне місце для питань між заняттями — Telegram-чат когорти, гілки QA і BA.

#Питання

Слайд 100

Заняття завершується однією думкою, яка об'єднує всі блоки.

Після цього — час для питань. Ось типові питання про завдання С2 і короткі відповіді.

Можна здати в той самий форк, що в С1? Ні. С2 — новий проєкт, тому потрібен новий форк із koldovsky/ai-qa-ba-c2.

Робити і BA, і QA? Ні, лише свою роль.

Можна взяти демо-вимогу? Ні. Демо-варіант не зараховується; ваш варіант — той самий, що в С1.

Обов'язково Given/When/Then? Ні. Підходить Given/When/Then або однозначне твердження, яке можна перевірити.

Чи потрібен токен-звіт? У С2 — ні.

Чи треба агент для С2? Ні, підходить будь-який інструмент. Агент потрібен з С3.

Можна взяти AC з відповіді AI без змін? Можна, якщо ви звірили їх з вимогою. У розділі 6 звіту має бути видно, що саме ви перевірили, — а зазвичай щось доводиться виправити.

Питання, на які не вистачило часу на занятті, ставте в чат когорти — відповідь буде там.

Дві дати, які варто запам'ятати: