vyvchy
    Теми розділу

    01 · Основи тестування

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

    Зміст

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    User story + AC

    Рев'ю вимог: питання, дірки, дефекти вимог

    Тест-дизайн: чеклист + детальні кейси

    Unit-рівень: логіка знижки й округлення — розробник

    API-рівень: валідація, помилки, ліміти — QA, не чекаючи UI

    Системний рівень: наскрізний сценарій у браузері

    Дефекти: завести, пріоритизувати, ретест

    Смоук білда + регресія кошика на стейджі

    Звіт і залишковий ризик

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

    User story + AC

    Рев'ю вимог: питання, дірки, дефекти вимог

    Тест-дизайн: чеклист + детальні кейси

    Unit-рівень: логіка знижки й округлення — розробник

    API-рівень: валідація, помилки, ліміти — QA, не чекаючи UI

    Системний рівень: наскрізний сценарій у браузері

    Дефекти: завести, пріоритизувати, ретест

    Смоук білда + регресія кошика на стейджі

    Звіт і залишковий ризик

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

    Unit-рівень — територія розробника: обчислення відсотка, порівняння дат терміну дії, округлення. 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 — саме на живих прикладах ця пара перестає плутатися (механіка — у главі про баг-репорти):

    ДефектSeverityPriority
    Знижка застосовується й до вартості доставкиMajorHigh
    У двох вкладках код застосовується двічіMajorMedium
    Повідомлення про помилку англійською замість українськоїMinorHigh

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

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

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

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

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

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

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

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

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

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

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

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

    Підсумок

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

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

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

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

    Джерела

    • ISTQB Certified Tester Foundation Level, силабус v4.0 — глава наскрізно спирається на розділи 1 («Основи тестування»), 2 («Тестування протягом SDLC») і 5 («Управління тестовою діяльністю»).
    • Глосарій ISTQB — канонічні означення термінів: acceptance criteria, entry/exit criteria, severity, priority, regression testing.