Наскрізний кейс: фіча від вимоги до релізу

Зміст

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

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

Вихідна точка: user story і критерії приймання

Аналітик приносить user story: «Як покупець, я хочу ввести промокод у кошику, щоб отримати знижку на замовлення». До неї — (acceptance criteria, AC):

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

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

Питання аналітику й розробнику

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

Аналітику — про правила гри:

Знижка рахується від суми товарів чи від суми з доставкою?
Код чутливий до регістру? SUMMER10 і summer10 — один код чи два?
Що з товарами, які вже мають знижку, — промокод додається зверху чи ні?
Користувач застосував код, а потім змінив кошик — знижка перераховується, скидається чи заморожується?
Ліміт використань — один на користувача, на замовлення чи глобальний на весь код?
Як округлюємо: 10% від 99,99 — це 9,99 чи 10,00?

Розробнику — про механізм:

Де валідується код — на фронтенді, на бекенді чи в обох місцях? (Правильна відповідь — завжди на бекенді; фронтова валідація — лише зручність.)
Що повертає API на невалідний код: який статус-код і яке тіло помилки?
Застосований код зберігається в сесії чи прив'язується до замовлення в базі? Що станеться з двома відкритими вкладками?
Чи є , яким промокоди можна вимкнути без релізу?
Які частини вже покриті , а що лишається на наш рівень?

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

Мінімально достатня документація

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

Для промокоду розумний мінімум такий:

Артефакт	Що містить	Навіщо
Чеклист перевірок	20–30 однорядкових пунктів, згрупованих за AC	Основний робочий інструмент
3–5 детальних кейсів	Кроки для складної логіки: округлення, зміна кошика, дві вкладки	Повторюваність там, де легко помилитись
Баг-репорти	За стандартною структурою	Комунікація з розробкою
Підсумок тестування	Що покрито, що знайдено, що лишилось	Основа рішення про реліз

Кожен пункт чеклиста мапиться на конкретний AC — це спрощена ідея , яку ми зачепили в главі про вимоги: наприкінці має бути видно, що жоден критерій не лишився без перевірки і жодна перевірка не висить у повітрі. Повноцінна (requirements traceability matrix, RTM) для однієї фічі — надмір; для регульованих доменів на кшталт фінтеху — норма. Рівень формальності — рішення, а не даність, і воно має бути свідомим.

Проходження рівнями й видами

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

Модульний рівень — територія розробника: обчислення відсотка, порівняння дат терміну дії, округлення. QA ці тести не пише, але питання «що з цього покрито модульними тестами?» ставить обов'язково — щоб не дублювати ту саму математику дорогими UI-перевірками.

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

// Playwright: протермінований код має повернути 422 і код помилки
test('expired promo code is rejected', async ({ request }) => {
  const response = await request.post('/api/cart/promo', {
    data: { code: 'EXPIRED2025' },
  });
  expect(response.status()).toBe(422);
  expect(await response.json()).toMatchObject({ error: 'PROMO_EXPIRED' });
});

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

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

Дефекти: заведення і пріоритизація

Припустимо, тестування принесло три знахідки. Розкладемо їх за severity і priority — саме на живих прикладах ця пара перестає плутатися (механіка — у главі про баг-репорти):

Дефект	Severity	Priority
Знижка застосовується й до вартості доставки	Major	High
У двох вкладках код застосовується двічі	Major	Medium
Повідомлення про помилку англійською замість української	Minor	High

Пояснення до кожного рядка. Перший дефект б'є по грошах напряму і масово — лагодити до релізу, тут усе очевидно. Другий технічно серйозний (компанія теж втрачає гроші), але сценарій з двома вкладками рідкісний — виправлення можна взяти наступним патчем, якщо реліз горить. Третій функціонально дрібниця, але його побачить кожен користувач, який помилився в коді, — і саме тому пріоритет високий: severity описує технічний вплив, priority — порядок роботи, і вони незалежні.

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

Атач добирається під знахідку, і по нашій трійці це видно наочно. «Знижку на доставку» доводить мережа: HAR-експорт із панелі Network, знятий під час відтворення запиту /api/cart/promo, — це JSON-формат вивантаження зафіксованої сесії, який читають різні інструменти, тож розробник розбирає її в себе так само, як ви в себе. Косметичній помилці з англійським текстом вистачить . А якщо ту саму знахідку принесла не ручна перевірка, а впала автоматизована регресія кошика, — атачем іде Playwright-: GUI-інструмент, який дає розібрати записаний прогін уже після того, як скрипт відпрацював.

Смоук і регресія перед релізом

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

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

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

Рішення про готовність

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

Роль QA — звірити стан із (exit criteria), які зафіксовані заздалегідь, ще на етапі планування (звідки вони беруться — у главі про тест-план). Для нашої фічі вони можуть звучати так: усі AC покриті перевірками і пройдені; немає відкритих дефектів рівня critical/major; регресія кошика зелена. Такий список і є відповіддю на питання, старше за Scrum: «can we mark it as done?» — так формулював ключову міру готовності Білл Вейк у SMART-задачах. Там же видно, чому рядок про регресію стоїть у переліку нарівні з рештою: серед складових готовності названо «tests are included» — тести входять у неї, а не йдуть окремою стадією після. І далі — звіт людською мовою: що перевірено, що знайдено й виправлено, що лишилося відкритим і який ризик команда бере на борт, релізячи зараз. «Відкритий дефект з двома вкладками: подвійна знижка, сценарій рідкісний, фіксимо в наступному патчі» — це формулювання, з яким менеджер може ухвалити рішення; голе «є баг» — ні.

Тут же спрацьовує сьомий принцип тестування — хибність відсутності дефектів (absence-of-defects fallacy): зелені прогони не гарантують, що фіча потрібна і зручна. Якщо на UAT (user acceptance testing) з'ясується, що покупці шукають поле промокоду на сторінці оплати, а не в кошику, — технічно бездоганний реліз усе одно провалить свою мету. Тому демо і приймання бізнесом — не формальність після тестування, а його частина.

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

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

Підсумок

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

Можливі питання

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

«Тобі дали нову фічу — розкажи свої дії від постановки до релізу». Інтерв'юер дивиться на порядок: кандидат, який починає з «відкриваю застосунок і клікаю», програє тому, хто починає з питань до вимог.
«Вимог немає або вони на два рядки — що робитимеш?» Очікувана відповідь: зібрати вимоги самому — питання аналітику, поведінка поточної версії, аналоги в конкурентів — і зафіксувати домовленості письмово, а не тестувати навмання.
«Реліз завтра, а ти не встигаєш перевірити все — що ріжеш?» Перевіряють ризик-орієнтоване мислення: різати найменш ризикове, критичний шлях грошей — недоторканний, і про зрізане чесно сказати в звіті.
«Знайшов критичний баг за годину до релізу — твої дії?» Дивляться, чи кандидат комунікує (негайно повідомити команду з фактами й впливом), а не мовчки блокує чи мовчки пропускає.
«Хто вирішує, що фіча готова до релізу?» Пастка на зрілість: відповідь «я, QA» — червоний ; правильна рамка — критерії виходу плюс поінформоване рішення власника продукту.

Джерела

Вихідна точка: user story і критерії приймання

ISTQB CTFL Syllabus v4.0 — критерії приймання як умови завершеності історії й пряме читання: їх «may be viewed as the test conditions that should be exercised by the tests».

Мінімально достатня документація

ISTQB CTFL Syllabus v4.0 — склад баг-репорту й вимога трасування: перевірки мають бути звʼязані з елементами , а рівень формальності — рішення команди.

Проходження рівнями й видами

ISTQB CTFL Syllabus v4.0 — рівні тестування й теза, що будь-який вид застосовний на будь-якому рівні; там же — раннє залучення тестування до появи коду.
ISTQB — Certified Tester Foundation Level (CTFL) v4.0 — силабус декларує релевантність для всіх підходів до доставки — , Agile, DevOps, Continuous Delivery: розкладка фічі за рівнями не залежить від процесу команди.

Дефекти: заведення і пріоритизація

ISTQB CTFL Syllabus v4.0 — severity як «degree of impact» і priority як «priority to fix» — два незалежні поля репорту, між якими силабус не задає залежності.
ISTQB Glossary — сильніша форма межі: severity приписана дефекту, priority — задачі.
Chrome DevTools — Network features reference — HAR як формат експорту зафіксованої мережевої сесії: JSON-обʼєкт із певним набором полів, який читають різні HTTP-інструменти.
Playwright — Trace viewer — трейс як GUI-розбір записаного прогону вже після того, як скрипт відпрацював; саме його прикріпляють до дефекту, знайденого автотестом.

Смоук і регресія перед релізом

ISTQB CTFL Syllabus v4.0 — розведення підтверджувального й регресійного тестування і те, що обсяг регресії звужує impact analysis.
ISTQB Glossary — smoke testing означено через готовність обʼєкта до запланованого тестування — саме та роль, яку смоук виконує перед релізом.

Рішення про готовність

ISTQB CTFL Syllabus v4.0 — критерії виходу й прийнятий стейкхолдерами залишковий ризик як умова завершення тестування; звіт адаптується під аудиторію, а рішення лишається за власником продукту.
The 2020 Scrum Guide — Definition of Done як зобовʼязання інкремента: поки він не виконаний, робота готовою не вважається.
Bill Wake — INVEST in Good Stories, and SMART Tasks — прообраз того самого критерію задовго до Scrum: «can we mark it as done?» як ключова міра, серед складових якої названо «tests are included».

Тобі дали нову фічу — розкажи свої дії від постановки до релізу

Головне в цьому питанні — порядок, і починається він не з . Спочатку рев'ю вимог: прочитати user story та acceptance criteria і знайти дірки питаннями до аналітика й розробника — половина дефектів знімається ще до першого рядка коду. Далі мінімально достатня документація: чеклист перевірок, змапований на AC, плюс кілька детальних кейсів для складної логіки. Потім перевірки рівнями знизу вгору: логіку покривають розробника, валідацію ганяю через API, не чекаючи інтерфейсу, наскрізний сценарій — у браузері. Знайдені дефекти заводжу з розкладкою за severity і priority; після фіксів — білда, ретест виправленого і зони впливу на . Фінал — звіт: що перевірено, що лишилося відкритим і який , а рішення про реліз ухвалює власник продукту. Кандидат, який починає відповідь з «відкриваю застосунок і клікаю», програє тому, хто починає з питань до вимог.

Чому тестування фічі починається до того, як з'явився білд?

Бо найдешевший дефект — дефект вимоги. Питання на рев'ю user story коштує годину розмови; той самий дефект, знайдений на проді, — відкат релізу. Механізм простий: поки вимога — це текст, її виправлення не тягне за собою ні переписування коду, ні ретесту, ні регресії. Типовий приклад — округлення: питання «10% від 99,99 — це 9,99 чи 10,00?» нерідко виявляє, що ніхто про це не думав, і дефект вимоги знімається за день до того, як став би дефектом коду. Тому рев'ю вимог і питання — це повноцінне тестування без запуску застосунку, а не «підготовка до тестування».

Чим питання до аналітика відрізняються від питань до розробника?

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

Вимог немає або вони на два рядки — що робитимеш?

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

Скільки тест-документації потрібно для типової фічі?

Мінімально достатньо: документація потрібна рівно настільки, наскільки в неї є читач і повторне використання. Розумний мінімум — чеклист із 20–30 однорядкових пунктів, згрупованих за acceptance criteria, плюс 3–5 детальних кейсів із кроками лише для складної логіки, де легко помилитися: округлення, зміна кошика після застосування коду, дві вкладки. До цього — баг-репорти за стандартною структурою і короткий підсумок тестування як основа рішення про реліз. Розписати п'ятдесят детальних кейсів — день роботи, який ніхто не прочитає. Рівень формальності — свідоме рішення, а не даність: у регульованих доменах на кшталт фінтеху повна документація може бути нормою.

Навіщо мапити перевірки на acceptance criteria?

Щоб наприкінці було видно дві речі: жоден критерій не лишився без перевірки і жодна перевірка не висить у повітрі. Це спрощена ідея : кожен пункт чеклиста прив'язаний до конкретного AC. Побічний ефект — сильніші баг-репорти: дефект із посиланням на погоджений критерій не потребує дискусій «а чи це взагалі баг». Повноцінна (requirements traceability matrix, RTM) для однієї фічі — надмір, а для регульованих доменів — норма; важливо, що це усвідомлений вибір рівня формальності, а не звичка «так заведено».

Навіщо QA цікавитися модульними тестами, якщо він їх не пише?

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

Чому частину перевірок варто робити через API, не чекаючи UI?

Бо API-рівень дає найбільший виграш у часі: зазвичай готовий раніше за інтерфейс, і всю логіку валідації можна перевірити, поки фронтенд ще пишеться. Протермінований код, чужий код, повторне застосування, порожній рядок — усе це через API б'ється швидше і стабільніше, ніж крізь браузер. До того ж контракт помилок — і тіло — сам по собі об'єкт перевірки: якщо з розробником погодили 422 з машиночитним кодом помилки, а приходить 500, це знахідка ще до першого UI-тесту. На системному рівні тоді лишається те, чого API не покаже: стан на клієнті, повідомлення, верстка.

Що перевіряється на системному рівні такого, чого не видно через API?

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

Чим severity відрізняється від priority і чому це незалежні осі?

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

Що треба зробити перед тим, як завести дефект у трекер?

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

Чим відрізняються смоук, ретест і регресія?

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

Як визначити обсяг регресії перед релізом? Реліз завтра, все не встигаєш — що ріжеш?

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

Знайшов критичний баг за годину до релізу — твої дії?

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

Хто вирішує, що фіча готова до релізу, і яка тут роль QA?

Рішення про реліз ухвалює власник продукту або менеджер — не QA: тільки вони тримають повний контекст — обіцянки клієнтам, маркетингові дати, ціну відкладення. Роль QA — звірити стан із (exit criteria), зафіксованими ще на плануванні: усі AC покриті й пройдені, немає відкритих дефектів рівня critical/major, регресія зони впливу зелена. І далі — звіт людською мовою: що перевірено, що знайдено й виправлено, що лишилося відкритим і який команда бере на борт, релізячи зараз. «Відкритий дефект з двома вкладками: подвійна знижка, сценарій рідкісний, фіксимо в наступному патчі» — формулювання, з яким можна ухвалити рішення; голе «є баг» — ні. Відповідь «я, QA, даю добро на реліз» на співбесіді — червоний .

Усі AC пройдені, смоук і регресія зелені. Чи гарантує це успішний реліз?

Ні — і це сьомий принцип тестування, хибність відсутності дефектів (absence-of-defects fallacy). Зелені прогони гарантують лише те, що система відповідає перевіреним вимогам, а не те, що фіча потрібна і зручна. Якщо на UAT (user acceptance testing) з'ясується, що покупці шукають поле промокоду на сторінці оплати, а не в кошику, — технічно бездоганний реліз однаково провалить свою мету. Тому демо аналітику чи власнику продукту і приймання бізнесом — не формальність після тестування, а його частина. Сильна відповідь розрізняє «система працює за вимогами» і «система розв'язує проблему користувача»: перше доводять тести, друге — приймання і зворотний зв'язок.

Три кейси навколо тієї самої фічі «промокод у кошику»: розкладання acceptance criteria на чеклист із і пошуком дірок, API- негативних перевірок у Playwright за погодженим контрактом і фінальна розкладка знахідок зі звітом за день до релізу.

Кейс 1. Від чотирьох AC до чеклиста: трасування і дірки

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

AC	Перевірки в чеклисті
Валідний код зменшує суму	Застосування на кошик із кількох товарів; кошик з одним товаром; сума перераховується одразу; сума на сторінці оплати збігається з кошиком
Код має термін дії	Код в останній день дії працює; протермінований відхиляється; дірка: день закінчення включно чи ні?
Один код на замовлення	Другий код поверх застосованого відхиляється; повторне застосування того самого коду; дірка: заміна коду — можна зняти перший і ввести другий?
Зрозуміле повідомлення про помилку	Неіснуючий код; протермінований код; порожнє поле; повідомлення українською, без технічних деталей

Окремий список — перевірки, які не мапляться на жоден AC: округлення (10% від 99,99), чутливість до регістру, зміна кошика після застосування коду, дві відкриті вкладки, товари з наявною знижкою.

Що дивитися і чому:

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

Кейс 2. API-рівень: негативні перевірки, не чекаючи UI

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

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

// контракт помилок, погоджений з розробником: 422 + код у тілі
const invalidCases = [
  { code: 'EXPIRED2025', error: 'PROMO_EXPIRED' }, // термін дії минув
  { code: 'NOSUCHCODE1', error: 'PROMO_NOT_FOUND' }, // код не існує
  { code: '', error: 'PROMO_EMPTY' }, // порожній рядок
];

for (const { code, error } of invalidCases) {
  test(`invalid promo "${code}" returns 422 ${error}`, async ({ request }) => {
    const response = await request.post('/api/cart/promo', { data: { code } });
    expect(response.status()).toBe(422);
    expect(await response.json()).toMatchObject({ error });
  });
}

test('second promo on top of applied one is rejected', async ({ request }) => {
  await request.post('/api/cart/promo', { data: { code: 'SUMMER10' } });
  const second = await request.post('/api/cart/promo', {
    data: { code: 'WINTER15' },
  });
  expect(second.status()).toBe(422);
  expect(await second.json()).toMatchObject({ error: 'PROMO_ALREADY_APPLIED' });
});

Що дивитися і чому:

Асерти беруться з контракту, а не з фантазії. Якщо замість погодженого 422 приходить 400 — розмова з розробником про контракт; якщо 500 на порожньому рядку — це вже знахідка: сервер має відмовляти контрольовано, а не падати.
Табличні кейси — пункти чеклиста один в один. Кожен рядок invalidCases трасується до AC про повідомлення й термін дії; додати новий негативний сценарій — один рядок у масиві.
Ці перевірки не дублюються на UI. Логіку валідації закрили тут — швидко і стабільно; на системному рівні лишається шлях покупця: поле вводу, повідомлення на екрані, знижка після оновлення сторінки.
Кейс із другим кодом — перевірка стану, не формату. Вона вимагає підготовленого кошика із застосованим кодом, тож у сюїті потрібна ізоляція між тестами — інакше повторний прогін почне з «брудного» кошика.

Кейс 3. День до релізу: розкласти знахідки і написати звіт

Тестування принесло три знахідки. зафіксовані на плануванні: всі AC покриті й пройдені; немає відкритих critical/major; кошика зелена.

Дефект	Severity	Priority	Логіка
Знижка застосовується й до доставки	Major	High	Б'є по грошах масово — лагодити до релізу
У двох вкладках код застосовується двічі	Major	Medium	Технічно серйозно, але сценарій рідкісний — можна патчем
Повідомлення про помилку англійською	Minor	High	Дрібниця, але бачить кожен, хто помилився в коді

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

Підсумок тестування: промокод у кошику

Покриття: всі 4 AC закриті перевірками (чеклист 26/26 пройдено),
API-сюїта негативних перевірок зелена, регресія кошика й оплати зелена.

Виправлено і ретестовано: знижка на доставку (#1042),
англомовне повідомлення про помилку (#1044).

Відкрито: #1043 — у двох вкладках код застосовується двічі (major/medium).
Сценарій вимагає двох одночасних сесій кошика — на реальних користувачах
рідкісний. Фікс запланований у наступний патч.
Ризик релізу зараз: подвійна знижка на поодиноких замовленнях.

Критерії виходу виконані, крім відкритого #1043.
Рішення про реліз із цим відомим ризиком — за власником продукту.

Що дивитися і чому:

Severity і priority розійшлися у двох рядках із трьох. Саме на живих прикладах ця пара перестає плутатися: severity — технічний вплив, priority — порядок роботи, і вони незалежні.
Звіт називає , а не ставить діагноз «можна/не можна». QA не ухвалює рішення про реліз — він дає картину, з якою власник продукту може його ухвалити: що відкрито, наскільки ймовірно, який план фікса.
Відхилення від критеріїв виходу не ховається. «Виконані, крім #1043» — чесна рамка: команда свідомо бере на борт, а не дізнається про нього з прода.

Старт: вимоги і питання

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

Документація

Розумію принцип мінімальної достатності: артефакт існує, лише якщо в нього є читач і повторне використання; розумний мінімум — чеклист 20–30 пунктів за AC + 3–5 детальних кейсів для складної логіки + баг-репорти + підсумок тестування.
Можу пояснити «перевірка ↔ AC»: жоден критерій без перевірки, жодна перевірка не висить у повітрі.
Знаю, чому повна RTM для однієї фічі — надмір, а для регульованих доменів (фінтех) — норма, і що рівень формальності — свідоме рішення.

Рівні і види

Можу розкласти перевірки фічі за рівнями: логіка — модульні тести (розробник), валідація і помилки — API, наскрізний шлях і стан — UI; дублювати той самий шар на кількох рівнях — марнотратство.
Знаю, чому API-рівень дає найбільший виграш у часі: готовий раніше за інтерфейс, негативні перевірки швидші й стабільніші, ніж через браузер.
Можу пояснити, що видно лише на системному рівні: знижка після оновлення сторінки, зрозумілість повідомлень, верстка, узгодженість сум між кошиком, оплатою і листом.
Пам'ятаю про нефункціональні шари поруч із функціональним ядром: usability повідомлень, мобільна ширина, навантаження — хоча б озвучити команді.

Дефекти

Знаю різницю severity vs priority: технічний вплив vs порядок роботи; осі незалежні.
Можу навести приклади розходження: Minor/High — англомовне повідомлення, яке бачить кожен; Major/Medium — подвійна знижка в рідкісному сценарії з двома вкладками.
Знаю дисципліну перед заведенням: пошук дублікатів, мінімальні кроки відтворення, фактичний/очікуваний результат із посиланням на AC, атачі.

Смоук, ретест, регресія

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

Рішення про реліз

Розумію рамку: QA не ухвалює рішення про реліз, а дає чесну картину — звіт із (що перевірено, що виправлено, що відкрито, який береться на борт — не голе «є баг»); рішення — за власником продукту, бо в нього повний контекст (обіцянки, дати, ціна відкладення).
Знаю, що (exit criteria) фіксуються заздалегідь на плануванні, і можу навести приклад набору: AC покриті й пройдені, немає відкритих critical/major, регресія зони впливу зелена.
Пам'ятаю хибність відсутності дефектів: зелені прогони не гарантують, що фіча потрібна і зручна; демо і UAT — частина тестування, а не формальність після нього.

Знайшли помилку?