Сценарії використання й приймальні критерії

Зміст

Техніки з попередніх глав — класи еквівалентності, граничні значення, таблиці рішень — відповідають на питання «як перевірити поле чи бізнес-правило». Але вимоги рідко приходять полями. У реальній команді вони приходять user story з приймальними критеріями або сценаріями використання, і перше робоче питання QA звучить інакше: «як із цього тексту зробити перевірки й нічого не загубити?»

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

Use case: актор, потоки, винятки

Сценарій використання (use case) — це опис взаємодії між актором і системою, яка веде актора до його цілі. Актор (actor) — не конкретна людина, а роль: «покупець», «адміністратор», а іноді й зовнішня система — платіжний шлюз теж актор, просто не людський.

Класична структура use case:

Передумови (preconditions) — що має бути істинним до старту: «в кошику є товар».
Основний потік (basic flow) — послідовність кроків, якою актор досягає цілі, коли все йде добре. Його і називають happy path.
Альтернативні потоки (alternative flows) — легальні відгалуження, які теж ведуть до цілі, але іншим шляхом: оплата збереженою карткою замість нової, вхід гостем замість логіну.
Виняткові потоки (exception flows) — ситуації, коли ціль не досягається або досягається з відхиленням: банк відхилив платіж, сесія протухла посеред оформлення.
Післяумови (postconditions) — що гарантовано істинне після завершення: «замовлення створене, лист надіслано» або, для винятку, «замовлення не створене, кошик не втрачено».

На прикладі «Оплата замовлення карткою»:

Тут один основний потік (залогінений покупець, платіж пройшов), один альтернативний (гість) і один винятковий (відмова банку). У живому продукті гілок буде більше — таймаут 3-D Secure, обрив мережі після списання, повторне натискання «Оплатити», — і саме заради цих гілок use case і пишуть: вони змушують автора вимоги відповісти на «а що, як ні?» ще до розробки.

Тести зі сценаріїв

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

Але сценарій відповідає лише за маршрут. Усередині кроків живуть дані й правила, і там працюють інші техніки:

поле «номер картки» на кроці D — класи еквівалентності й граничні значення;
правило «безкоштовна доставка від 1000 грн разом із промокодом» — таблиця рішень;
статуси замовлення після оплати — переходи станів.

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

User story і формати приймальних критеріїв

User story — це коротке формулювання потреби у форматі «Як роль, я хочу дію, щоб цінність»: «Як покупець, я хочу зберегти картку, щоб не вводити її щоразу». Story навмисно не специфікація — це обіцянка розмови. В agile-практиці це описують як «3 C»: Card (картка — сам текст), Conversation (розмова — деталі зʼясовуються в обговоренні), Confirmation (підтвердження — приймальні критерії).

Приймальні критерії (acceptance criteria, AC) — це і є та третя «C»: перелік умов, за яких story вважається виконаною. Для QA це головний тестовий базис у Scrum-команді: з AC виводяться перевірки, і за AC вирішується, чи приймати фічу. Атрибути вимог загалом — тема розділу «Основи тестування»; тут важливо одне: критерій, який не можна перевірити, — не критерій. «Сторінка працює швидко» — побажання; «список карток віддається не довше ніж за 2 секунди на тестовому стенді» — критерій.

Силабус ISTQB називає два найпоширеніші формати запису AC:

Формат	Як виглядає	Коли зручний
Правила (rule-oriented)	Маркований список умов: «картка зберігається лише після успішного платежу», «максимум 5 збережених карток»	Обмеження, валідації, поодинокі правила
Сценарний (scenario-oriented)	Given-When-Then: стан → дія → результат	Поведінка з контекстом: «за якого стану що станеться»

Формати не конкурують — їх змішують в одній story. Правило «максимум 5 карток» безглуздо розтягувати на Given-When-Then, а поведінку «що бачить гість після відмови банку» безглуздо стискати в один рядок правила.

Given-When-Then як формат критерію

Given-When-Then (GWT) — спосіб записати критерій як мінімальний сценарій із трьох частин:

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

Given залогінений покупець із товаром у кошику на 1200 грн
When він оплачує замовлення карткою, яку банк відхиляє
Then він бачить повідомлення про відмову без технічних деталей
And замовлення не створюється, кошик лишається без змін

Чому цей формат прижився: він змушує автора назвати всі три речі, які найчастіше гублять у вимогах. Без Given незрозуміло, з якого стану стартуємо (а від стану залежить результат). Без чіткого When у критерії ховаються дві-три дії одразу. Без перевірюваного Then виходить «система коректно обробляє помилку» — а що саме бачить користувач і що лишається в даних, невідомо.

Три робочі правила гігієни GWT:

Один When. Якщо дій дві — це два сценарії або погано схований е2е-флоу.
Then — лише те, що можна спостерігати: текст на екрані, статус у базі, надісланий запит. «Система обробляє виняток» — не Then.
Без деталей реалізації. «When натискає синю кнопку в правому куті» привʼязує критерій до верстки; критерій описує намір, а не піксель.

Важливо не плутати рівні: GWT — це формат мислення й запису, він не вимагає жодного інструмента. Gherkin — конкретний синтаксис (файли .feature, кроки, автоматизація через Cucumber/CodeceptJS BDD), який використовує ті самі ключові слова. Команда може писати AC у GWT в Jira і ніколи не мати жодного .feature-файлу — і це нормально. Звʼязка Gherkin з кодом — тема розділу про фреймворки автоматизації.

Наскрізні сценарії vs атомарні перевірки

З одного use case можна зробити два принципово різні види тестів, і обидва потрібні.

Наскрізний сценарій (end-to-end) проходить увесь потік від передумови до післяумови: гість кладе товар у кошик, оформлює, платить, бачить підтвердження, отримує лист. Його цінність — інтеграційна: він ловить баги на стиках кроків, які жоден локальний тест не побачить (кошик губиться після логіну, лист іде без номера замовлення).

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

// Атомарна перевірка: один інваріант, падіння одразу вказує на причину
test('промокод SAVE10 зменшує підсумок на 10%', async ({ page }) => {
  await openCartWithItems(page, { total: 1000 });
  await applyPromo(page, 'SAVE10');
  await expect(page.getByTestId('cart-total')).toHaveText('900 грн');
});

// Наскрізний сценарій: ціль користувача цілком, ловить стики кроків
test('гість оформлює замовлення карткою і бачить підтвердження', async ({ page }) => {
  await addItemToCart(page, 'item-42');
  await checkoutAsGuest(page, guestData);
  await payWithCard(page, testCard.valid);
  await expect(page.getByTestId('order-confirmation')).toBeVisible();
});

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

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

Пастка happy-path-only

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

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

Як ламати пастку системно, а не «нюхом»:

До кожного When — питання «а що, як ні?». Банк підтвердив — а якщо відхилив? А якщо не відповів узагалі? Кожна відповідь — кандидат у винятковий потік.
До кожного AC — негативний близнюк. «Картка зберігається після успішного платежу» тягне за собою «картка НЕ зберігається після неуспішного».
Стандартний список зривів для будь-якого флоу: обрив мережі посеред кроку, повторне натискання кнопки-сабміту, «назад» у браузері, протухла сесія, паралельна дія в другій вкладці, недостатні права.
Питання про гроші й дані: що з уже списаними коштами, введеними даними, станом кошика, коли потік обірвався? Післяумова виняткового потоку — найчастіше саме те місце, де вимога мовчить, а баг коштує найдорожче.

Хороший маркер зрілості вимог: якщо в use case розділ винятків порожній — це привід іти до аналітика з питаннями ще до початку тестування, а не заповнювати дірки здогадками під час нього.

Типові помилки

Виглядає як «усі AC покриті — фіча протестована», а насправді AC — мінімальний контракт приймання, зазвичай зміщений у бік happy path; покриття AC — це нижня межа, а не вичерпний тест-дизайн.
Виглядає як «AC у Given-When-Then — це вже майже автотести», а насправді GWT — формат опису поведінки; тестом він стає лише після додавання даних, середовища й перевірюваних очікувань, а автотестом — після звʼязування з кодом кроків.
Виглядає як «наскрізний сценарій покриває все, атомарні тести зайві», а насправді падіння е2е не локалізує причину, а його довжина множить флак; е2е доводить прохідність маршруту, атомарні — коректність правил.
Виглядає як «use case і user story — синоніми», а насправді story — коротка обіцянка цінності з критеріями приймання, а use case — структурований опис взаємодії з потоками й винятками; story поміщається на стикері, use case — ні.
Виглядає як «додам у сценарій більше кроків — буде більше покриття», а насправді довгий сценарій ламкіший і повільніший, а перевірки всередині нього дублюють атомарні тести; покриття росте від нових потоків, а не від довших маршрутів.

Підсумок

Use case = актор + потоки: основний, альтернативні, виняткові, з перед- і післяумовами. Мінімум покриття — один тест на кожен потік.
Сценарій дає карту маршрутів, а глибину в кожній точці дають техніки: еквівалентність і межі — полям, таблиці рішень — правилам, переходи станів — статусам.
AC записують правилами або сценарно (Given-When-Then); неперевірюваний критерій — не критерій. У GWT: один When, спостережуваний Then, без деталей реалізації.
Наскрізних сценаріїв мало (прохідність маршрутів), атомарних перевірок багато (локалізація причин). Це не конкуренти, а два шари.
Happy path — зазвичай найменш імовірне місце для бага. До кожного When питай «а що, як ні?», до кожного AC шукай негативного близнюка.

Що питають на співбесіді

«Ось user story з трьома AC — як тестуватимеш?» Класика. Інтервʼюер чекає, що ти не кинешся перелічувати кліки, а спершу структуруєш: потоки, дані в кроках, техніки до даних — і явно назвеш винятки, яких в AC немає. Питання до вимоги («а що при відмові банку?») тут плюс, а не мінус.
«Що таке acceptance criteria і хто їх пише?» Дивляться на розуміння процесу: AC — спільна робота власника продукту, розробки і QA (та сама Conversation), а не документ, який QA отримує згори.
«Поясни Given-When-Then. Чим відрізняється від Gherkin?» Перевіряють, чи відрізняєш формат мислення від синтаксису інструмента. Бонус — назвати гігієну: один When, перевірюваний Then.
«Чим use case відрізняється від user story?» Хочуть почути про структуру: потоки й винятки проти короткої обіцянки цінності з критеріями.
«У тебе година на фічу — ганяєш один довгий е2е чи багато дрібних перевірок?» Пастка на «або-або»: сильна відповідь — про шари, пріоритет за ризиком і те, що довгий сценарій не локалізує падіння.
«Усі AC пройшли, а в проді баг. Як так?» Перевіряють, чи розумієш межі AC як тестового базису — і чи не звучить у відповіді «вимоги були погані» замість «мій тест-дизайн мав вийти за межі написаного».

Джерела

ISTQB CTFL Syllabus v4.0 — розділ 4.5 «Collaboration-based Test Approaches»: спільне написання user story, приймальні критерії, ATDD. Тестування за use case як окрема техніка описане в попередній версії силабусу (CTFL 2018, розділ 4.2.5).
ISTQB Glossary — канонічні означення: use case, actor, acceptance criteria, user story.
Martin Fowler, GivenWhenThen — коротке канонічне пояснення формату; авторство Фаулер атрибутує Деніелу Терхорст-Норту і Крісу Маттсу (BDD).
Gherkin Reference — Cucumber — синтаксис Gherkin: чим інструментальний шар відрізняється від GWT-формату критеріїв.

Що таке сценарій використання (use case) і з чого він складається?

Use case — це опис взаємодії між актором і системою, яка веде актора до його цілі. Класична структура: передумови (що має бути істинним до старту), основний потік (кроки, коли все йде добре, — той самий happy path), альтернативні потоки (легальні відгалуження, які теж ведуть до цілі), виняткові потоки (ціль не досягається або досягається з відхиленням) і післяумови (що гарантовано істинне після завершення). Сенс структури в тому, що вона змушує автора вимоги відповісти на «а що, як ні?» ще до розробки. Для QA use case — готова карта маршрутів: з неї виводяться тести, щонайменше по одному на кожен потік.

Хто такий актор (actor) в use case? Це завжди людина?

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

Чим альтернативний потік відрізняється від виняткового?

Обидва — відгалуження від основного потоку, різниця в результаті. Альтернативний потік — легальний інший шлях до тієї самої цілі: оплата збереженою карткою замість нової, оформлення гостем замість логіну. Винятковий потік — ситуація, коли ціль не досягається або досягається з відхиленням: банк відхилив платіж, сесія протухла посеред оформлення. Для тестування різниця в очікуваннях: в альтернативному потоці перевіряється та сама післяумова, що й в основному (замовлення створене), у винятковому — власна післяумова винятку (замовлення не створене, кошик не втрачено). Саме післяумови виняткових потоків — місце, де вимога найчастіше мовчить, а баг коштує найдорожче.

Що таке user story і що означають «3 C»?

User story — коротке формулювання потреби у форматі «Як роль, я хочу дію, щоб цінність»: «Як покупець, я хочу зберегти картку, щоб не вводити її щоразу». Story навмисно не специфікація — це обіцянка розмови. «3 C» розшифровуються так: Card (картка — сам текст story), Conversation (розмова — деталі зʼясовуються в обговоренні), Confirmation (підтвердження — приймальні критерії). Для QA з цього випливає головне: деталі поведінки не «десь записані», їх зʼясовують у розмові, і питання до вимоги — нормальна частина процесу, а не ознака слабкого тестувальника.

Чим use case відрізняється від user story?

Це не синоніми, хоч на співбесідах їх регулярно плутають. Story — коротка обіцянка цінності з приймальними критеріями: вона поміщається на стикері й свідомо лишає деталі на розмову. Use case — структурований опис взаємодії: актор, передумови, основний потік, альтернативні й виняткові потоки, післяумови — на стикер він уже не влазить. Практична різниця для тестування: use case явно перелічує відгалуження й винятки, а в story винятки в критерії потрапляють рідко й безсистемно — тому за story тест-дизайн мусить сам добудовувати те, про що текст мовчить.

Що таке acceptance criteria і хто їх пише?

Приймальні критерії (acceptance criteria, AC) — перелік умов, за яких story вважається виконаною; це і є третя «C» — Confirmation. Для QA у Scrum-команді це головний тестовий базис: з AC виводяться перевірки, і за AC вирішується, чи приймати фічу. Пишуться вони не «згори»: AC — спільна робота власника продукту, розробки і QA, та сама Conversation. Ключова вимога до кожного критерію — перевірюваність: «сторінка працює швидко» — це побажання, а «список карток віддається не довше ніж за 2 секунди на тестовому стенді» — критерій. Неперевірюваний критерій на рев'ю вимог — законний привід для питання, а не для здогадок.

Які формати запису AC існують і коли який зручніший?

Силабус ISTQB називає два найпоширеніші. Rule-oriented — маркований список правил-умов: «картка зберігається лише після успішного платежу», «максимум 5 збережених карток»; зручний для обмежень, валідацій, поодиноких правил. Scenario-oriented — Given-When-Then: стан, дія, результат; зручний для поведінки з контекстом, коли результат залежить від стану. Формати не конкурують — їх змішують в одній story: правило «максимум 5 карток» безглуздо розтягувати на три рядки GWT, а поведінку «що бачить гість після відмови банку» безглуздо стискати в один рядок правила.

Поясни Given-When-Then. Чим він відрізняється від Gherkin?

GWT — формат запису критерію як мінімального сценарію з трьох частин: Given — стан світу до дії (передумови, дані, контекст), When — одна дія актора чи системи, Then — спостережуваний результат, який можна перевірити. Це формат мислення й запису — він не вимагає жодного інструмента: команда може писати AC у GWT в Jira і не мати жодного .feature-файлу. Gherkin — конкретний синтаксис (файли .feature, кроки, автоматизація через Cucumber/CodeceptJS BDD), який використовує ті самі ключові слова. Плутати рівні — типова помилка: «AC у GWT — це майже автотести» не працює, бо тестом сценарій стає лише після додавання даних, середовища й перевірюваних очікувань, а автотестом — після звʼязування з кодом кроків.

Які правила гігієни Given-When-Then варто назвати на співбесіді?

Три. Перше — один When: якщо дій дві, це два сценарії або погано схований е2е-флоу. Друге — Then містить лише те, що можна спостерігати: текст на екрані, статус у базі, надісланий запит; «система обробляє виняток» — не Then. Третє — без деталей реалізації: «натискає синю кнопку в правому куті» привʼязує критерій до верстки, а критерій описує намір, не піксель. Формат прижився саме тому, що змушує автора назвати три речі, які найчастіше гублять у вимогах: стартовий стан, конкретну дію і перевірюваний результат.

Дають use case з діаграмою потоків. Скільки тестів потрібно як мінімум?

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

Як use case поєднується з класами еквівалентності, межами й таблицями рішень?

Use case — не заміна технік, а рамка, яка показує, де їх застосувати. Сценарій дає карту маршрутів, техніки — глибину в конкретних точках карти: поле «номер картки» на кроці введення — класи еквівалентності й граничні значення, бізнес-правило на кшталт «безкоштовна доставка від 1000 грн разом із промокодом» — таблиця рішень, статуси замовлення після оплати — переходи станів. Тут дві симетричні помилки: типовий джун проходить щасливий маршрут і вважає фічу покритою, а ретельний джун закопується в 40 варіантів одного поля й не перевіряє жодного альтернативного потоку. Правильний рух — спершу карта потоків, потім техніки в точках, де живуть дані й правила.

Наскрізний сценарій і атомарна перевірка — навіщо потрібні обидва?

Це два різні шари з різною цінністю. Наскрізний (end-to-end) сценарій проходить увесь потік від передумови до післяумови, і його цінність інтеграційна: він ловить баги на стиках кроків, які жоден локальний тест не побачить — кошик губиться після логіну, лист іде без номера замовлення. Атомарна перевірка фіксує один інваріант («шосту картку зберегти не можна»), і її цінність — локалізація: коли вона падає, причина видна з назви тесту. Самими наскрізними обійтися не можна: довгий сценарій падає на будь-якому з десяти кроків і каже лише «десь у флоу зламалось», а кожен крок — це UI-очікування й мережа, тобто повільність і флак. Самими атомарними теж: сто зелених локальних перевірок не гарантують, що користувач здатен пройти флоу цілком.

У тебе година на фічу — ганяєш один довгий е2е чи багато дрібних перевірок?

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

Що таке пастка happy-path-only і чому вона виникає системно, а не через лінощі?

Це найпоширеніший перекіс у тестуванні за сценаріями: перевірений лише основний потік. Причина вбудована в самі артефакти: user story за побудовою описує бажану поведінку, автор AC думає про цінність фічі, а не про відмови, тож винятки в критерії потрапляють рідко й безсистемно. Тестувальник, який чесно покрив усі написані AC, автоматично успадковує цей перекіс — усі тести зелені, а продакшн ловить перший таймаут платіжки. Додається симетрична проблема: щасливий шлях — це те, що розробник і так проганяв руками під час розробки, тож імовірність знайти баг саме там — найнижча з усіх потоків. Баги живуть у гілках, про які ніхто не подумав.

Як системно шукати виняткові потоки, яких немає в AC?

Чотири прийоми замість «нюху». Перший — до кожного When ставити питання «а що, як ні?»: банк підтвердив — а якщо відхилив? а якщо не відповів узагалі? Другий — до кожного AC шукати негативного близнюка: «картка зберігається після успішного платежу» тягне за собою «картка НЕ зберігається після неуспішного». Третій — стандартний список зривів для будь-якого флоу: обрив мережі посеред кроку, повторне натискання кнопки-сабміту, «назад» у браузері, протухла сесія, паралельна дія в другій вкладці, недостатні права. Четвертий — питання про гроші й дані: що з уже списаними коштами, введеними даними, станом кошика, коли потік обірвався? І окремий маркер зрілості вимог: якщо розділ винятків у use case порожній — це привід іти до аналітика з питаннями ще до тестування, а не заповнювати дірки здогадками під час нього.

Усі AC пройшли, а в проді баг. Як таке можливо?

Тому що AC — мінімальний контракт приймання, а не вичерпний тест-дизайн, і за побудовою він зміщений у бік happy path. Покриття всіх AC — нижня межа: воно доводить, що обіцяне працює, але мовчить про винятки, зриви й комбінації, яких автор критеріїв не передбачив. Механізм той самий, що в пастці happy-path-only: винятки потрапляють в AC рідко, тож «усе покрито» означає лише «покрито написане». Практичний висновок — тест-дизайн має виходити за межі написаного: негативні близнюки до кожного AC, стандартний список зривів, питання до аналітика про порожні винятки. На співбесіді тут є ще один шар: слабка відповідь звучить як «вимоги були погані», сильна — «мій тест-дизайн мав вийти за межі написаного, і ось якими прийомами я це роблю».

Три кейси з робочого життя QA: розкласти user story з трьома AC на потоки, техніки й винятки (те, що просять зробити на співбесіді майже дослівно); відремонтувати погано написані критерії до перевірюваного Given-When-Then; і розкласти автотести на два шари — атомарні перевірки плюс один наскрізний сценарій.

Кейс 1. Від user story до перевірок: «Збереження картки»

Прилітає story зі спринту:

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

AC1. Картка зберігається лише після успішного платежу. AC2. Можна мати щонайбільше 5 збережених карток. AC3. Збережена картка показується замаскованою — лише останні 4 цифри.

Слабкий хід — перекласти три AC у три тест-кейси й вважати роботу зробленою. Системний хід — чотири кроки.

Крок 1: маршрути. Основний потік: оплата новою карткою з увімкненим «зберегти», платіж успішний, картка зʼявилась у списку. Альтернативний: оплата вже збереженою карткою (ціль та сама — оплачено, але шлях інший). Виняткові: банк відхилив платіж; банк не відповів (таймаут). Кожен маршрут — щонайменше один тест.

Крок 2: негативні близнюки до кожного AC. AC1 тягне за собою «картка НЕ зберігається після неуспішного платежу» — цього рядка в story немає, але без нього AC1 не перевірений. AC2 тягне «шосту зберегти не можна» — і питання, що саме бачить користувач при спробі. AC3 тягне «повний номер не приходить у відповіді API» — маскування лише на фронті означає, що номер усе одно їде мережею.

Крок 3: техніки всередині кроків. Правило «максимум 5» — це межа, тож перевіряємо трійку значень: 4 (зберігається), 5 (зберігається, ліміт досягнуто), 6 (відмова). Комбінація «галочка увімкнена/вимкнена × платіж успішний/відхилений» — готова таблиця рішень на чотири правила, з якої видно неочевидний випадок: галочка вимкнена, платіж успішний — картка не має зберегтися.

Крок 4: питання до аналітика. Що бачить користувач, коли карток уже 5, — заблокована галочка чи помилка після оплати? Чи зберігається картка при таймауті банку, якщо платіж потім таки пройшов? Це не причепливість: розділ винятків у story фактично порожній, і дірки закриваються питаннями до вимоги, а не здогадками.

Підсумкова карта перевірок:

Джерело	Перевірка	Тип
Основний потік	Оплата новою карткою з «зберегти» → картка в списку	наскрізний
Альтернативний потік	Оплата збереженою карткою → замовлення створене	наскрізний
Винятковий потік + близнюк AC1	Банк відхилив → картка не зберігається, кошик цілий	атомарна
AC2 + межі	4-та, 5-та зберігаються; 6-та — контрольована відмова	атомарні
AC3 + близнюк	У списку лише останні 4 цифри; повного номера немає у відповіді API	атомарні
Таблиця рішень	Галочка вимкнена + успішний платіж → картка не збережена	атомарна

Кейс 2. Ремонт критеріїв: до перевірюваного GWT

Реальні AC часто приходять у стані «усе зрозуміло, нічого не перевіриш». Три типові дефекти й ремонт кожного:

Було	Що зламано	Стало
«Система коректно обробляє помилки оплати»	Then не спостережуваний: що таке «коректно»?	Given покупець із кошиком на 1200 грн; When банк відхиляє платіж; Then видно повідомлення про відмову без технічних деталей, замовлення не створене, кошик без змін
«Користувач вводить картку, оплачує і бачить список збережених»	Два When в одному критерії — насправді це два сценарії	Розбити: окремо «оплата новою карткою проходить», окремо «збережена картка зʼявляється в списку»
«Після оплати натискає зелену кнопку "До замовлень" у шапці»	Деталі реалізації: критерій прибитий до верстки	When переходить до своїх замовлень; Then бачить створене замовлення зі статусом «Оплачено»

Відремонтований перший критерій у повному записі:

Given залогінений покупець із товаром у кошику на 1200 грн
When він оплачує замовлення карткою, яку банк відхиляє
Then він бачить повідомлення про відмову без технічних деталей
And замовлення не створюється, кошик лишається без змін

Що тут дивитись: у Then лише спостережуване (текст на екрані, стан замовлення, стан кошика), When один, і жодного слова про кнопки чи кольори. А правило «щонайбільше 5 карток» у GWT розтягувати не треба — воно лишається одним рядком rule-oriented формату: формати змішуються в одній story.

Кейс 3. Два шари автотестів на одну story

З карти кейсу 1 видно: наскрізних сценаріїв два, атомарних перевірок більше. У Playwright шари виглядають так:

// Атомарні перевірки: один інваріант на тест, падіння одразу називає причину
test('шоста картка не зберігається: ліміт 5', async ({ page }) => {
  await loginWithSavedCards(page, { count: 5 });
  await payWithNewCard(page, testCard.valid, { saveCard: true });
  await expect(page.getByTestId('save-card-error')).toHaveText(
    'Досягнуто ліміт збережених карток',
  );
});

test('після відхиленого платежу картка не зберігається', async ({ page }) => {
  await loginWithSavedCards(page, { count: 0 });
  await payWithNewCard(page, testCard.declined, { saveCard: true });
  await expect(page.getByTestId('payment-declined')).toBeVisible();
  await expect(savedCardsCount(page)).resolves.toBe(0);
});

// Наскрізний сценарій: ціль користувача цілком, ловить стики кроків
test('покупець зберігає картку при оплаті й платить нею при наступному замовленні', async ({ page }) => {
  await addItemToCart(page, 'item-42');
  await payWithNewCard(page, testCard.valid, { saveCard: true });
  await expect(page.getByTestId('order-confirmation')).toBeVisible();

  await addItemToCart(page, 'item-43');
  await payWithSavedCard(page, { last4: testCard.valid.last4 });
  await expect(page.getByTestId('order-confirmation')).toBeVisible();
});

Що тут дивитись:

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

Use case: структура й потоки

Знаю визначення use case (взаємодія актора й системи, що веде до цілі) і пʼять елементів структури: передумови, основний потік, альтернативні й виняткові потоки, післяумови; актор — роль, а не людина, і платіжний шлюз — теж актор.
Знаю різницю альтернативний vs винятковий потік: перший веде до цілі іншим шляхом, у другому ціль не досягається або досягається з відхиленням.
Розумію, що післяумова виняткового потоку («замовлення не створене, кошик не втрачено») — окремий предмет перевірки, і саме там вимоги мовчать найчастіше.

Тести зі сценаріїв

Знаю мінімальне правило покриття: кожен потік — основний, альтернативний, винятковий — проходиться хоча б одним тестом.
Розумію, що use case дає карту маршрутів, а глибину дають техніки: еквівалентність і межі — полям, таблиці рішень — правилам, переходи станів — статусам.
Можу назвати дві симетричні помилки: пройти лише happy path — і закопатися в 40 варіантів одного поля, не перевіривши жодного альтернативного потоку.

User story і приймальні критерії

Знаю формат story «Як роль, я хочу дію, щоб цінність», «3 C» (Card, Conversation, Confirmation) — і що story не специфікація, а acceptance criteria — третя «C».
Можу пояснити різницю use case vs user story: структурований опис із потоками й винятками проти короткої обіцянки цінності з критеріями.
Знаю два формати AC за ISTQB: rule-oriented (список правил) і scenario-oriented (Given-When-Then) — і що їх змішують в одній story.
Можу пояснити, чому неперевірюваний критерій — не критерій, і переформулювати «працює швидко» у вимірюване твердження.
Розумію, що AC — спільна робота власника продукту, розробки і QA, а не документ, який QA отримує згори.

Given-When-Then

Можу назвати три частини GWT і що фіксує кожна: стан до дії → одна дія → спостережуваний результат.
Знаю три правила гігієни: один When; Then — лише спостережуване; без деталей реалізації («синя кнопка в правому куті» — не критерій).
Розрізняю GWT (формат мислення й запису, живе хоч у Jira) і Gherkin (синтаксис інструмента: .feature-файли, Cucumber/CodeceptJS BDD).

Наскрізні сценарії vs атомарні перевірки

Знаю цінність кожного шару: е2е ловить баги на стиках кроків, атомарна перевірка локалізує причину падіння з назви тесту.
Можу обґрунтувати баланс: атомарних багато, наскрізних мало — по одному на основний потік і критичні альтернативні/виняткові, а не по одному на кожен AC.
Розумію, чому довший сценарій не означає більше покриття: покриття росте від нових потоків, а довжина лише множить флак і час.

Пастка happy-path-only

Розумію системну причину перекосу: story описує бажану поведінку, тож винятки потрапляють в AC рідко — а happy path розробник і так проганяв руками, тож імовірність бага там найнижча.
Можу застосувати прийоми злому пастки: «а що, як ні?» до кожного When, негативний близнюк до кожного AC, стандартний список зривів (обрив мережі, повторний сабміт, «назад», протухла сесія, друга вкладка, недостатні права).
Знаю маркер зрілості вимог: порожній розділ винятків у use case — привід іти до аналітика до початку тестування, а не заповнювати дірки здогадками.