Вимоги, user story та acceptance criteria

Зміст

Кожен тест відповідає на питання «а як має бути правильно?». Джерело цього «правильно» — вимоги: саме вони є основою тестування (test basis) і оракулом, з яким ти порівнюєш фактичну поведінку. Немає вимог — немає критерію, і «баг» перетворюється на «мені здається, що так не повинно бути». Тому глава про вимоги — це не про документообіг, а про фундамент будь-якої перевірки, яку ти напишеш у тест-кейсах.

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

Функціональні і нефункціональні вимоги

Вимога (requirement) — це умова або здатність, яку система повинна мати, щоб розвʼязати задачу користувача чи бізнесу. Вимоги ділять на два великі класи:

Функціональні (functional) — описують, що система робить: поведінку, функції, реакції на вхідні дані. «Користувач може відновити пароль через email», «при сумі замовлення від 1000 грн доставка безкоштовна».
Нефункціональні (non-functional) — описують, наскільки добре вона це робить: атрибути якості системи. Продуктивність, безпека, зручність використання, надійність, сумісність.

Аспект	Функціональна вимога	Нефункціональна вимога
Відповідає на питання	Що робить система?	Наскільки добре / за яких умов?
Приклад	«Пошук повертає товари за назвою і артикулом»	«Результати пошуку зʼявляються не довше ніж за 2 секунди при 1000 одночасних користувачів»
Типова перевірка	Функціональний тест: дія → очікуваний результат	Спеціалізовані види: навантажувальні, security, usability
Типовий дефект формулювання	Пропущений сценарій (а що при помилці?)	Немає вимірюваного порога («має працювати швидко»)

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

Атрибути хороших вимог

Стандарт ISO/IEC/IEEE 29148 (інженерія вимог, requirements engineering) описує характеристики якісних вимог — окремих та їх наборів. Найважливіші з них для щоденної роботи QA:

Атрибут	Питання-перевірка
Однозначність (unambiguous)	Чи можуть двоє людей прочитати це по-різному?
Повнота (complete)	Чи описані всі сценарії, зокрема помилкові? Чи немає «і т.д.», «тощо», «за потреби»?
Тестопридатність (verifiable)	Чи можна обʼєктивно перевірити, що вимогу виконано? Є критерій pass/fail?
Атомарність (singular)	Одна вимога — одне твердження, без «і» на пʼять функцій одразу
Несуперечливість (consistent)	Чи не конфліктує з іншими вимогами системи?
Необхідність (necessary)	Чи справді це потрібно користувачу/бізнесу, чи «про запас»?
Здійсненність (feasible)	Чи реалізовно це технічно в межах проєкту?

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

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

User story і INVEST

В Agile-командах вимоги найчастіше живуть у формі користувацьких історій (user story) — коротких описів потреби з погляду користувача за шаблоном:

Як [роль], я хочу [дію/можливість], щоб [цінність]. (As a… / I want… / So that…)

Наприклад: «Як покупець, я хочу зберігати товари у списку бажань, щоб повернутися до них пізніше, не шукаючи заново».

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

Якість story оцінюють за критеріями INVEST (сформулював Білл Вейк):

Літера	Критерій	Що означає	Навіщо це QA
I	Independent	Незалежна від інших story	Можна протестувати й випустити окремо, без черги блокерів
N	Negotiable	Обговорювана, не жорсткий контракт	Деталі зʼясовуються в розмові — момент поставити питання
V	Valuable	Несе цінність користувачу	Частина «щоб…» — це і є критерій, чи те взагалі перевіряємо
E	Estimable	Команда може оцінити обсяг	Якщо оцінити не виходить — вимога незрозуміла, це сигнал
S	Small	Вміщається у спринт	Величезну story неможливо покрити тестами за ітерацію
T	Testable	Можна перевірити	Немає способу перевірити — story не готова до розробки

Антиприклад: «Зробити модуль оплати». Це не story, а епік: немає ролі й цінності, не оцінити, не вміщається у спринт, «зробити» не перевіриш. Його ріжуть на менші історії: «Як покупець, я хочу оплатити замовлення карткою, щоб не платити готівкою курʼєру» — і далі окремо про збережені картки, повернення коштів, помилки оплати.

INVEST — не академічна вправа: на рефайнменті беклогу (див. Agile для QA) саме за цими критеріями команда вирішує, чи брати story у спринт, а «Testable» — прямо зона відповідальності тестувальника.

Acceptance criteria: чекліст і Given/When/Then

Критерії приймання (acceptance criteria, AC) — це умови, які мають виконуватися, щоб story вважалася завершеною. Їх формулюють до початку розробки — зазвичай власник продукту разом з командою, і QA тут не читач, а співавтор. AC — це той самий Confirmation з трьох «C» і водночас головний вхід для тест-дизайну.

На практиці живуть два формати.

Чекліст (rule-oriented) — список правил без привʼязки до сценарію:

Пароль містить щонайменше 8 символів, серед них цифра і літера.
При невалідному email кнопка «Зареєструватися» неактивна.
Після реєстрації користувач отримує лист із підтвердженням протягом 5 хвилин.
Email, що вже зареєстрований, показує повідомлення «Обліковий запис уже існує».

Формат зручний для наборів правил валідації, обмежень, розрахунків.

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

Scenario: Успішний логін
  Given зареєстрований користувач із підтвердженим email
  When він вводить правильний email і пароль та натискає «Увійти»
  Then він потрапляє на дашборд
  And бачить своє імʼя в шапці сторінки

Цей формат — синтаксис мови Gherkin і основа підходу BDD (behavior-driven development); механіку звʼязування таких сценаріїв із кодом автотестів розбирають розділи про стратегію та інструменти автоматизації. Але цінність Given/When/Then не в інструментах: він змушує описати стан → дію → результат, і в цій трійці одразу видно дірки («а що в Then, якщо пароль неправильний?»).

Структура Given/When/Then напряму лягає на структуру автотесту (той самий поділ, що й Arrange–Act–Assert):

// AC: Given зареєстрований користувач, When вводить валідні креденшили,
// Then потрапляє на дашборд
test('логін з валідними даними веде на дашборд', async ({ page }) => {
  await page.goto('/login');                                    // Given
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Пароль').fill('correct-password');
  await page.getByRole('button', { name: 'Увійти' }).click();   // When
  await expect(page).toHaveURL(/\/dashboard/);                  // Then
});

Важлива межа, яку плутають на співбесідах: AC — не тест-кейси. AC фіксують «що має бути правдою», щоб прийняти story, — це мінімальний контракт. Тест-дизайн іде ширше: до кожного критерію додаються негативні перевірки, граничні значення, комбінації. З одного AC про мінімальну довжину пароля народжується кілька перевірок: рівно 8 символів, 7 символів, порожнє поле, пробіли, unicode. AC кажуть «що приймаємо», тести відповідають «як ми в цьому переконалися».

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

Тестування вимог

Вимоги можна і треба тестувати — без жодного запуску коду. Це найдешевша форма тестування: рев'ю вимог — класика статичного тестування (докладно — у главі про статичне тестування і рев'ю), а «раннє тестування зберігає час і гроші» — один із семи принципів. Фаза аналізу вимог недарма стоїть першою у STLC.

Що саме шукає QA, читаючи вимогу:

Неоднозначність. «Система повідомляє користувача про помилку» — як саме: на екрані, листом, пушем? Кого саме, якщо користувачів у сценарії двоє?
Прогалини. Описаний happy path — а що при відмові платіжки, обриві мережі, паралельному редагуванні? Що бачить користувач без прав?
Суперечності. Вимога 12 каже «сесія живе 30 хвилин», вимога 47 — «користувач залишається залогіненим 7 днів». Обидві не можуть бути правдою одночасно.
Нетестопридатність. «Інтерфейс має бути інтуїтивним» — за яким критерієм приймаємо?
Конфлікт із наявною поведінкою. Нова вимога мовчки ламає сценарій, який вже працює і який хтось любить.

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

Що робити без вимог

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

Люди. Аналітик, власник продукту, розробник фічі, сапорт — носії знання «як має бути». Питай і фіксуй відповіді письмово.
Артефакти. Макети в Figma, листування, старі баг-репорти, наявні тести, документація користувача — усе це фрагменти вимог.
Сам застосунок. Поточна поведінка — базлайн для регресії. Але обережно: поточна поведінка не обовʼязково правильна — вона лише «так є зараз», а не «так має бути».
Аналоги і конвенції. Як цю задачу розвʼязують конкуренти, які конвенції в платформи (валідація email, формати дат), здоровий глузд домену.

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

RTM: матриця трасованості

Матриця трасованості вимог (requirements traceability matrix, RTM) — це таблиця відповідності між вимогами й тестами: кожен рядок показує, які перевірки покривають конкретну вимогу. RTM відповідає на два питання: «чи всі вимоги покриті хоч одним тестом?» і «які тести зачепить зміна цієї вимоги?». Побудова, підтримка і межі корисності RTM — окрема глава про покриття вимог і трасування в розділі «Тест-дизайн»; тут достатньо означення і місця в загальному ланцюжку:

Ланцюжок працює в обидва боки: вниз — від потреби до перевірки, вгору — від дефекта, знайденого тестом, до вимоги, яку він порушує (або якої бракувало).

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

Виглядає як «у нас є вимоги», а насправді — вікі-сторінки дворічної давнини, які ніхто не оновлював після змін. Тестувати проти застарілого документа гірше, ніж без нього: оракул впевнено бреше. Перше питання до будь-якої вимоги — «вона ще актуальна?».
Виглядає як acceptance criteria, а насправді — тест-кейс із кроками «натиснути кнопку в правому верхньому куті». AC описують поведінку, а не реалізацію; кроки і локатори — рівень тест-кейсу.
Виглядає як user story, а насправді — епік «зробити оплату» без ролі, цінності й меж. Прогін за INVEST це виявляє за хвилину: не Small, не Estimable, не Testable.
Виглядає як «AC пройшли — фіча протестована», а насправді AC — мінімальний контракт приймання. Негативні сценарії, межі, комбінації — це тест-дизайн поверх AC, а не замість них.
Виглядає як «нефункціональне — не моя парафія», а насправді саме тестувальник першим має спитати «скільки це — швидко?». Нетестопридатна вимога — це дефект, і його заведення нічим не гірше за баг у коді.

Підсумок

Вимоги — основа тестування й оракул: якість твоїх тестів обмежена якістю вимог, тому вимоги тестують так само, як код, — тільки раніше й дешевше.
Функціональні вимоги описують «що робить система», нефункціональні — «наскільки добре»; нефункціональна вимога без вимірюваного порога — нетестопридатна.
User story — обіцянка розмови (Card–Conversation–Confirmation), а не міні-специфікація; фільтр якості story — INVEST, і «T» у ньому — territory тестувальника.
Acceptance criteria пишуться до розробки, описують «що», а не «як», і є входом для тест-дизайну — але не замінюють його.
Без вимог тестування можливе: збери оракули (люди, артефакти, поточна поведінка, аналоги), сформулюй припущення письмово й провалідуй їх у власника продукту.

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

«Чим функціональні вимоги відрізняються від нефункціональних? Наведи приклади.» Чекають пару «що робить / наскільки добре» і власні приклади, а не завчені означення. Сильна відповідь додає: нефункціональні без чисел — нетестопридатні.
«Що таке user story і що означає INVEST?» Розшифрувати літери мало — інтервʼюер дивиться, чи розумієш ти навіщо кожен критерій. Найцінніша літера для QA — Testable: покажи це.
«Що таке acceptance criteria? Хто і коли їх пише?» Ключові слова: до розробки, разом із командою, критерій готовності story. Бонус — обидва формати: чекліст і Given/When/Then.
«Чим AC відрізняються від тест-кейсів?» Класична пастка. AC — контракт «що приймаємо», тест-кейси — ширший набір перевірок поверх нього, включно з негативними і граничними.
«Вимог немає. Твої дії?» Перевіряють зрілість: паніка «без вимог тестувати неможливо» — червоний прапорець. Чекають структуру: зібрати оракули → зафіксувати припущення → провалідувати → перетворити на чекліст.
«Як би ти протестував саму вимогу?» Чекають список: однозначність, повнота, несуперечливість, тестопридатність — з прикладом поганого формулювання і як його виправити.
«Що таке RTM?» Достатньо означення (таблиця вимоги × тести) і двох питань, на які вона відповідає: покриття і вплив змін.

Джерела

ISTQB CTFL Syllabus v4.0 — розділ 4.5 «Collaboration-based Test Approaches»: спільне написання user story, acceptance criteria, ATDD; рев'ю вимог — у розділі 3 «Static Testing».
ISO/IEC/IEEE 29148:2018 — стандарт інженерії вимог: характеристики якісних вимог.
Bill Wake — INVEST in Good Stories, and SMART Tasks — першоджерело акроніма INVEST.
Martin Fowler — GivenWhenThen — стисле пояснення формату Given/When/Then.
Gherkin Reference — Cucumber — синтаксис Gherkin: Scenario, Given/When/Then, And/But.

Що таке вимога і чому вимоги називають основою тестування?

Вимога (requirement) — умова або здатність, яку система повинна мати, щоб розвʼязати задачу користувача чи бізнесу. Кожен тест відповідає на питання «а як має бути правильно?», і джерело цього «правильно» — саме вимоги: вони є основою тестування (test basis) і оракулом, з яким порівнюється фактична поведінка. Немає вимоги — немає критерію pass/fail, і «баг» перетворюється на «мені здається, що так не повинно бути». Практичний наслідок: якість тестів обмежена якістю вимог, тому сильний тестувальник працює з вимогами так само прискіпливо, як з кодом.

Чим функціональні вимоги відрізняються від нефункціональних? Наведи приклади.

Функціональні описують, що система робить: поведінку, функції, реакції на вхідні дані — «користувач може відновити пароль через email», «при сумі замовлення від 1000 грн доставка безкоштовна». Нефункціональні описують, наскільки добре вона це робить: атрибути якості — продуктивність, безпека, зручність використання, надійність, сумісність. Приклад нефункціональної: «результати пошуку зʼявляються не довше ніж за 2 секунди при 1000 одночасних користувачів». Різниця тягне за собою і різницю в перевірках: функціональні закриваються тестами «дія → очікуваний результат», нефункціональні — спеціалізованими видами: навантажувальними, security, usability. Сильна відповідь додає: нефункціональна вимога без вимірюваного порога («має працювати швидко») — нетестопридатна, і саме QA має домогтися числа.

Які атрибути має хороша вимога?

За стандартом інженерії вимог ISO/IEC/IEEE 29148 якісна вимога однозначна (двоє людей не прочитають її по-різному), повна (описані всі сценарії, зокрема помилкові), тестопридатна (є обʼєктивний критерій pass/fail), атомарна (одне твердження, а не пʼять функцій через «і»), несуперечлива (не конфліктує з іншими вимогами), необхідна (справді потрібна, а не «про запас») і здійсненна (реалізовна технічно). На практиці найчастіше страждають однозначність, повнота й тестопридатність. Робочий прийом — читати вимогу з питанням «а чи можу я по цьому тексту зафіксувати pass/fail і чи прочитає розробник це так само, як я?». Кожна розбіжність трактувань, знайдена в тексті, — це дефект, спійманий до того, як його написали в коді.

Наведи приклад нетестопридатної вимоги. Як її виправити?

«Система має підтримувати багато користувачів» — нетестопридатна: незрозуміло, скільки це «багато», за яких умов і що вважати провалом. Виправлення — домогтися вимірюваності: «система витримує 500 одночасних активних сесій із часом відповіді API до 1 секунди для 95% запитів» — це вже прямий вхід для навантажувального тесту. Механізм виправлення завжди однаковий: питання «скільки? за яких умов? на якому обсязі даних?» перетворюють побажання на критерій. Є й маркери, які варто ловити оком під час читання: «швидко», «зручно», «інтуїтивно», «приблизно», «за можливості», «і т.д.» — кожне таке слово означає потенційно різне трактування у розробника й тестувальника. Нетестопридатна вимога — це дефект, і його заведення нічим не гірше за баг у коді.

Що таке user story і чим вона відрізняється від класичної вимоги?

User story — короткий опис потреби з погляду користувача за шаблоном «Як [роль], я хочу [дію/можливість], щоб [цінність]» (As a… / I want… / So that…). Ключова відмінність від класичної вимоги-документа: story — не повна специфікація, а обіцянка розмови; деталі зʼясовуються в обговоренні, а не виписані наперед. Це описує формула трьох «C» Рона Джеффріса: Card (короткий запис), Conversation (розмова, де аналітик, розробник і тестувальник зʼясовують деталі), Confirmation (acceptance criteria, за якими зрозуміло, що story готова). Для QA це означає, що робота починається не з готового документа, а з участі в розмові — саме тестувальник найчастіше питає «а що, як користувач зробить не так?».

Розшифруй INVEST. Навіщо кожен критерій саме тестувальнику?

INVEST (сформулював Білл Вейк) — критерії якості user story: Independent (незалежна — можна протестувати й випустити окремо), Negotiable (обговорювана — деталі зʼясовуються в розмові, це момент поставити питання), Valuable (несе цінність — частина «щоб…» каже, чи те взагалі перевіряємо), Estimable (оцінювана — якщо команда не може оцінити обсяг, вимога незрозуміла), Small (вміщається у спринт — величезну story не покрити тестами за ітерацію), Testable (перевірювана — немає способу перевірити, значить story не готова до розробки). Інтервʼюер дивиться не на завчені літери, а на розуміння «навіщо»: найцінніша для QA — Testable, це пряма зона відповідальності тестувальника. На рефайнменті беклогу саме за INVEST команда вирішує, чи брати story у спринт.

«Зробити модуль оплати» — це нормальна user story? Що з нею робити?

Ні, це епік, а не story, і прогін за INVEST виявляє це за хвилину: немає ролі й цінності, обсяг не оцінити (не Estimable), у спринт не вміщається (не Small), а «зробити» неможливо перевірити (не Testable). Такий запис ріжуть на менші історії з ролями і цінністю: «Як покупець, я хочу оплатити замовлення карткою, щоб не платити готівкою курʼєру» — і далі окремо про збережені картки, повернення коштів, помилки оплати. Практичний наслідок для QA: поки епік не порізаний, писати до нього тести нема з чого — немає перевірюваних тверджень. Сигналити про це на рефайнменті — нормальна робота тестувальника, а не причепливість.

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

Acceptance criteria (AC, критерії приймання) — умови, які мають виконуватися, щоб story вважалася завершеною. Ключові слова, яких чекає інтервʼюер: пишуться до початку розробки, зазвичай власником продукту разом з командою, і QA тут не читач, а співавтор. У термінах трьох «C» AC — це Confirmation: підтвердження, за яким видно, що story готова. Водночас AC — головний вхід для тест-дизайну: з них народжуються тестові умови й тест-кейси. Якщо AC пишуться після розробки — це червоний прапорець: команда спочатку щось зробила, а потім вигадує, що саме приймати.

Які формати acceptance criteria знаєш і коли який доречний?

На практиці живуть два формати. Чекліст (rule-oriented) — список правил без привʼязки до сценарію: «пароль містить щонайменше 8 символів», «при невалідному email кнопка неактивна»; зручний для наборів правил валідації, обмежень, розрахунків. Сценарний формат Given/When/Then описує поведінку через конкретний сценарій: Given — початковий стан і передумови, When — дія чи подія, Then — очікуваний спостережуваний результат. Це синтаксис мови Gherkin і основа BDD (behavior-driven development), але цінність формату не в інструментах: трійка «стан → дія → результат» змушує описати сценарій повністю, і дірки видно одразу — «а що в Then, якщо пароль неправильний?». Вибір формату — питання зручності для конкретного типу вимог, а не догма.

Чому Given/When/Then корисний, навіть якщо команда не використовує BDD-інструменти?

Бо його головна цінність — не автоматизація, а структура мислення: формат змушує явно назвати початковий стан (Given), дію (When) і спостережуваний результат (Then), і в цій трійці одразу видно прогалини вимоги. Якщо для якоїсь дії немає Then — сценарій не описаний; якщо Then неможливо спостерігати — критерій нетестопридатний. Додатковий бонус для AQA: структура Given/When/Then напряму лягає на структуру автотесту — це той самий поділ, що й Arrange–Act–Assert, тож AC у цьому форматі майже дослівно перетворюється на скелет тесту. Механіку звʼязування Gherkin-сценаріїв із кодом дають інструменти BDD, але користь формату починається раніше — на рівні тексту вимоги.

Чим acceptance criteria відрізняються від тест-кейсів?

Класична пастка співбесіди. AC фіксують «що має бути правдою», щоб прийняти story, — це мінімальний контракт приймання. Тест-дизайн іде ширше: до кожного критерію додаються негативні перевірки, граничні значення, комбінації. З одного AC про мінімальну довжину пароля у 8 символів народжується кілька перевірок: рівно 8, 7 символів, порожнє поле, пробіли, unicode. Тобто AC кажуть «що приймаємо», тести відповідають «як ми в цьому переконалися». Звідси і практичний висновок: «усі AC пройшли» не означає «фіча протестована» — негативні сценарії та межі лежать поверх AC, а не всередині них.

В AC написано: «під полем зʼявляється червоний div із текстом розміром 12px». Що з цим не так?

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

Як би ти протестував саму вимогу, ще до появи коду?

Рев'ю вимог — класика статичного тестування і найдешевша форма тестування взагалі: жодного запуску коду не потрібно. Що шукати: неоднозначність («система повідомляє користувача про помилку» — як саме: на екрані, листом, пушем?), прогалини (описаний happy path — а що при відмові платіжки, обриві мережі, користувачі без прав?), суперечності (вимога 12 каже «сесія живе 30 хвилин», вимога 47 — «залогінений 7 днів»), нетестопридатність («інтуїтивний інтерфейс» — за яким критерієм приймаємо?), конфлікт із наявною поведінкою (нова вимога мовчки ламає сценарій, який вже працює). Кожне поставлене питання — потенційно спійманий дефект, просто до коду. Важлива дисципліна фіксації: коментар до story, питання на рефайнменті, тред у трекері — головне, щоб відповідь стала частиною вимоги, а не залишилася в усній розмові.

Вимог немає або вони застаріли. Твої дії?

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

Чи можна тестувати проти застарілої документації, якщо іншої немає?

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

Що таке RTM і на які питання вона відповідає?

Матриця трасованості вимог (requirements traceability matrix, RTM) — таблиця відповідності між вимогами й тестами: кожен рядок показує, які перевірки покривають конкретну вимогу. Вона відповідає на два питання: «чи всі вимоги покриті хоч одним тестом?» (пошук дірок у покритті) і «які тести зачепить зміна цієї вимоги?» (аналіз впливу змін). Трасування працює в обидва боки: вниз — від бізнес-потреби через story та AC до тест-кейсів і результатів прогону, вгору — від дефекта, знайденого тестом, до вимоги, яку він порушує або якої бракувало. На співбесіді джуну достатньо означення і цих двох питань; глибина про побудову й межі корисності — окрема тема тест-дизайну.

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

Кейс 1. Рев'ю вимоги: розбираємо формулювання до коду

Аналітик приносить вимогу до нової фічі:

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

Виглядає як вимога, а насправді — набір маркерів проблем. Проганяємо по атрибутах:

Фрагмент	Атрибут, який страждає	Питання QA
«швидко»	Тестопридатність	Скільки це — швидко? 1 секунда? 10? За яких умов?
«повідомляє користувача»	Однозначність	Як саме: на екрані, листом, пушем? Кого, якщо замовлення оформив менеджер за клієнта?
«за потреби»	Однозначність, повнота	Хто і за яким правилом визначає потребу? При яких кодах помилки оплати пропонуємо повтор?
«тощо»	Повнота	Що ховається за «тощо»? Кожне нерозкрите слово — сценарій, який ніхто не реалізує і не перевірить
Одне речення про все	Атомарність	Тут щонайменше три вимоги: повідомлення про успіх, повідомлення про помилку, повтор оплати

Після обговорення вимога перетворюється на набір атомарних тверджень:

Після успішної оплати користувач бачить екран підтвердження з номером замовлення не довше ніж за 3 секунди після відповіді платіжного шлюзу.
При відмові платіжного шлюзу (будь-який код, крім успішного) користувач бачить повідомлення «Оплата не пройшла» і кнопку «Спробувати ще раз».
Лист із підтвердженням замовлення надходить на email покупця протягом 5 хвилин після успішної оплати.

Що тут важливо:

Кожне питання — потенційно спійманий дефект. Якби «за потреби» лишилося в тексті, розробник реалізував би своє трактування, тестувальник перевірив би своє — розбіжність виїхала б у прод.
Виправлена версія одразу тестопридатна. «Не довше ніж за 3 секунди» — прямий вхід для перевірки; «швидко» не перевіриш ніяк.
Фіксація письмова. Відповіді аналітика мають потрапити назад у вимогу (коментар до story, оновлений текст), інакше через місяць суперечка «баг чи фіча» почнеться заново.

Кейс 2. Від story до тестів: AC двома форматами і тест-дизайн поверх них

Story зі спринту:

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

Роль, дія, цінність на місці; по INVEST проходить. Confirmation — acceptance criteria. Правила валідації зручно скласти чеклістом (rule-oriented):

Пароль містить щонайменше 8 символів, серед них цифра і літера.
При невалідному email кнопка «Зареєструватися» неактивна.
Email, що вже зареєстрований, показує повідомлення «Обліковий запис уже існує».
Після реєстрації користувач отримує лист із підтвердженням протягом 5 хвилин.

А поведінковий сценарій із передумовою — у Given/When/Then, бо тут важливий стан системи до дії:

Scenario: Реєстрація з уже наявним email
  Given у системі існує обліковий запис із email "user@example.com"
  When відвідувач заповнює форму реєстрації з цим email і валідним паролем
  Then він бачить повідомлення «Обліковий запис уже існує»
  And новий обліковий запис не створюється

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

import { test, expect } from '@playwright/test';

// Один AC — «щонайменше 8 символів, серед них цифра і літера» —
// розгортається в набір перевірок навколо межі
const cases = [
  { password: 'abc12345', valid: true,  title: 'рівно 8 символів — межа проходить' },
  { password: 'abc1234',  valid: false, title: '7 символів — на один менше за межу' },
  { password: '',         valid: false, title: 'порожнє поле' },
  { password: 'abcdefgh', valid: false, title: '8 літер без цифри' },
  { password: '  ab12  ', valid: false, title: 'пробіли не рятують довжину' },
];

for (const c of cases) {
  test(`пароль: ${c.title}`, async ({ page }) => {
    await page.goto('/signup');                                       // Given
    await page.getByLabel('Email').fill('new-user@example.com');
    await page.getByLabel('Пароль').fill(c.password);                 // When
    const error = page.getByText('Пароль не відповідає вимогам');
    if (c.valid) {
      await expect(error).toBeHidden();                               // Then
    } else {
      await expect(error).toBeVisible();
    }
  });
}

Що тут важливо:

AC — не тест-кейси. У AC один рядок про пароль; у тестах — пʼять перевірок і це не межа. AC кажуть «що приймаємо», тести відповідають «як ми в цьому переконалися».
Тест-дизайн ловить дірки в AC. Спроба додати кейс абвгд123 (кирилиця) впирається в питання: чи «літера» в критерії включає unicode? В AC відповіді немає — це питання до власника продукту, тобто ще один дефект вимоги, спійманий до коду.
AC описують «що», тест — «як». У критерії — «бачить повідомлення»; конкретний локатор і текст живуть у тесті. Якщо в AC записати «червоний div під полем», критерій зламається при першому редизайні.

Кейс 3. Вимог немає: чекліст припущень як документація

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

Припущення	Звідки взято	Вердикт власника продукту
Експорт містить ті самі колонки, що й таблиця на екрані	Поточна поведінка UI	Підтверджено
Файл у кодуванні UTF-8, роздільник — кома	Конвенції платформи, аналоги в конкурентів	Підтверджено
Порожній результат пошуку дає файл із самими заголовками	Здоровий глузд домену	Змінено: кнопка експорту неактивна при порожньому результаті
Кількість рядків не обмежена	Ніде не знайдено — відкрите питання	Уточнено: ліміт 10 000 рядків, далі — повідомлення

Що тут важливо:

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

Функціональні і нефункціональні вимоги

Розумію, що вимоги — це основа тестування (test basis) і оракул: без них немає критерію pass/fail, а «баг» перетворюється на «мені так здається».
Можу пояснити різницю: функціональні — «що робить система», нефункціональні — «наскільки добре / за яких умов», і навести власну пару прикладів.
Знаю, що нефункціональна вимога без вимірюваного порога («має працювати швидко») нетестопридатна, і вмію довести її до числа питаннями «скільки? за яких умов? на якому обсязі даних?».
Розумію, чому дефект, спійманий у тексті вимоги, коштує годину обговорення, а той самий дефект у проді — реліз назад.

Атрибути хороших вимог

Знаю ключові характеристики якісної вимоги за ISO/IEC/IEEE 29148 — однозначність, повнота, тестопридатність, атомарність, несуперечливість, необхідність, здійсненність — і до кожної можу назвати питання-перевірку («чи можуть двоє людей прочитати це по-різному?»).
Ловлю оком маркери проблемної вимоги: «швидко», «зручно», «інтуїтивно», «приблизно», «за можливості», «як зазвичай», «і т.д.».

User story та INVEST

Знаю шаблон user story: як [роль], я хочу [дію], щоб [цінність] — і що частина «щоб…» відповідає на питання, чи є в story цінність узагалі.
Можу пояснити три «C» (Card, Conversation, Confirmation) і чому story — обіцянка розмови, а не міні-специфікація.
Розшифрую INVEST і поясню, навіщо QA кожен критерій; памʼятаю, що Testable — пряма зона відповідальності тестувальника.
Відрізняю story від епіка: «Зробити модуль оплати» валить Small, Estimable, Testable і не має ролі й цінності — його ріжуть на менші історії.

Acceptance criteria

Знаю, що AC формулюють до початку розробки — власник продукту разом із командою, і QA тут співавтор, а не читач.
Можу навести обидва формати AC: чекліст правил (rule-oriented) і сценарний Given/When/Then — та сказати, коли який зручніший.
Розумію Given/When/Then: початковий стан → дія → спостережуваний результат, і що ця трійка лягає на Arrange–Act–Assert в автотесті.
Можу пояснити класичну пастку співбесід «AC vs тест-кейси»: AC — мінімальний контракт «що приймаємо», тест-дизайн іде ширше — негативні перевірки, межі, комбінації.
Знаю, чому AC описують «що», а не «як»: деталі верстки в критерії привʼязують вимогу до реалізації, і критерій ламається при кожному редизайні.

Тестування вимог і робота без них

Знаю, що шукати при рев'ю вимоги: неоднозначність, прогалини (а що при помилці?), суперечності між вимогами, нетестопридатність, конфлікт із наявною поведінкою.
Розумію, що рев'ю вимог — статичне тестування і найдешевша форма пошуку дефектів: питання до вимоги — це баг, спійманий до коду.
Маю план дій без вимог: зібрати оракули (люди, артефакти, сам застосунок, аналоги й конвенції) → сформулювати припущення письмово → провалідувати у власника продукту.
Памʼятаю пастку: поточна поведінка застосунку — це «так є зараз», а не «так має бути»; вона базлайн для регресії, а не істина.
Можу дати означення RTM (таблиця вимоги × тести) і два питання, на які вона відповідає: чи всі вимоги покриті тестами і які тести зачепить зміна вимоги.