Рівні тестування

Назвіть рівні тестування і поясніть, чим вони відрізняються.

Класична модель — чотири рівні: модульний (unit), інтеграційний (integration), системний (system) і приймальний (acceptance). Розрізняє їх об'єкт тестування: окремий модуль в ізоляції → зв'язки між модулями → система цілком проти вимог → система в руках користувача. Кожен рівень має власну мету, власну тестову основу і власний типовий клас дефектів: логіка ловиться на модульному, стики й контракти — на інтеграційному, наскрізні сценарії — на системному, відповідність бізнес-потребі — на приймальному. Слабка відповідь — перелік назв; сильна для кожного рівня каже, що перевіряємо і які дефекти там живуть. Варто додати, що силабус ISTQB CTFL 4.0 виділяє п'ять рівнів — інтеграційний там розділено на компонентний і системний інтеграційний.

Чим рівень тестування відрізняється від виду тестування?

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

Що таке модульне (unit) тестування і хто його виконує?

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

Навіщо мануальному QA, який не пише unit-тести, розуміти цей рівень?

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

Що перевіряє інтеграційне тестування і які дефекти там типові?

Інтеграційне тестування перевіряє взаємодію між частинами: контракти, формати даних, послідовності викликів, обробку помилок на стиках. Типовий дефект цього рівня не видно всередині жодного окремого модуля — він живе саме між ними: модуль А повертає суму в копійках, модуль Б очікує в гривнях; сервіс А шле дату як 2026-07-16, сервіс Б парсить американський формат. Кожен модуль окремо при цьому проходить свої unit-тести — і саме тому «в нас усі модульні тести зелені» нічого не гарантує для зв'язки. Практичний наслідок: значна частина інтеграційних перевірок у сучасних проєктах іде через API, тому тестувальнику потрібні HTTP і REST як робочі інструменти.

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

Різниця в об'єкті: інтеграційне дивиться на стики між частинами, системне — на систему цілком проти вимог. Інтеграційний рівень перевіряє контракти, формати даних і обробку помилок між модулями чи сервісами; системний — наскрізні сценарії очима користувача на зібраній, розгорнутій системі з реальними інтеграціями, на середовищі, наближеному до продакшену. Різна і тестова основа: архітектура та контракти API проти вимог до системи. Відповідь у стилі «інтеграційне — це менше, системне — більше» — провал: різниця не в масштабі, а в тому, що саме є об'єктом перевірки. Лакмус: якщо на інтеграційному рівні ти тестуєш логіку всередині модуля — ти дублюєш unit-рівень і пропускаєш стики.

Що таке big bang, top-down і bottom-up? У чому ціна кожного підходу?

Це три класичні стратегії, у якому порядку збирати й перевіряти зв'язки між модулями. Big bang — зібрати все за один раз і тестувати готову зв'язку: підготовки нуль, але коли щось падає, дефект доводиться шукати по всій системі одразу — виправдано хіба для малих систем. Top-down іде від верхніх модулів до нижніх: скелет системи і головні сценарії видно рано, але відсутні нижні модулі треба підміняти стабами (stubs), а низькорівнева логіка перевіряється останньою. Bottom-up — навпаки, від нижніх до верхніх: критична низькорівнева логіка перевіряється першою, але потрібні драйвери (drivers), а працюючу систему цілком видно лише наприкінці. Інтерв'юер тут дивиться, чи розумієш ти саме ціну: big bang — дорога локалізація, top-down — стаби, bottom-up — драйвери.

Що таке stub і driver? Чим вони відрізняються?

Обидва — допоміжний код, який заміняє ще не готову чи не перевірену частину системи, а відрізняє їх напрямок підміни. Стаб (stub) імітує нижній модуль, який викликають: спрощена імітація, що повертає заготовлені відповіді, — потрібен у top-down, коли верхні рівні вже інтегруються, а нижніх ще немає. Драйвер (driver) імітує верхній рівень: смикає модуль так, як смикав би відсутній код зверху, — потрібен у bottom-up, коли нижні модулі вже зібрані, а викликати їх ще нікому. Просте мнемонічне правило: stub відповідає на виклики, driver їх ініціює.

Чому на практиці інтеграцію проводять інкрементно, а не big bang?

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

ISTQB CTFL 4.0 виділяє п'ять рівнів. Що за п'ятий і навіщо цей поділ?

П'ятий рівень з'являється з поділу інтеграційного на два: компонентний інтеграційний (component integration) — взаємодія модулів усередині системи, і системний інтеграційний (system integration) — взаємодія вашої системи з іншими системами: платіжним провайдером, поштовим сервісом. Поділ практичний, бо це різні задачі: всередині системи команда контролює обидві сторони стику, а зовнішню систему не контролює ніхто — інші релізні цикли, чужа документація, ліміти тестових середовищ. Питання «а як тестувати інтеграцію зі Stripe?» — це саме system integration. На співбесіді достатньо чотирьох рівнів, але згадка про цей поділ показує знання актуального силабуса.

Хто виконує системне тестування і чому важлива незалежність від розробників?

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

Чим UAT відрізняється від системного тестування?

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

У чому різниця між alpha- і beta-тестуванням?

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

Які форми приймального тестування існують, крім UAT?

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

Як рівні тестування пов'язані з V-моделлю і що означає «тестова основа визначає рівень»?

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

Баг відтворюється лише на зв'язці двох сервісів, окремо кожен працює. Що це каже про рівень і як діяти?

Це класичний портрет дефекту інтеграційного рівня: проблема живе на стику — контракт, формат даних, послідовність викликів чи обробка помилки між сервісами, — тому всередині кожного окремого сервісу її й не видно, і unit-тести обох чесно зелені. Якщо другий сервіс зовнішній (платіжка, пошта) — це system integration. Практичні кроки: локалізувати сам стик — зняти реальні запит і відповідь між сервісами й порівняти з контрактом; у баг-репорті адресувати дефект тому, хто порушив контракт, а не «обом командам разом», і додати пару request/response як доказ. Для команди це ще й сигнал про діру в покритті: інтеграційна перевірка цього з'єднання пропущена, і без неї баг повернеться після наступного рефакторингу будь-якої зі сторін.

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

Кейс 1. Одна фіча — чотири баги на чотирьох рівнях

Фіча: знижка 10% для замовлень від 1000 грн. За тиждень тестування і UAT прилетіли чотири скарги, які виглядають як «знижка не працює». Насправді це чотири дефекти різних рівнів — і чотири різні адресати.

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

• Симптом один — «знижка не працює», а дефекти різні. Рівень визначає не формулювання скарги, а об'єкт: логіка функції, стик, наскрізний сценарій чи бізнес-потреба. Перше питання тріажу — «де саме живе розбіжність?».
• Другий рядок — найчастіша плутанина. «Рахується неправильно» і «рахується правильно, але відображається неправильно» — дефекти різних рівнів: перший шукають у функції, другий — на стику. Пара запит/відповідь з мережевої панелі відрізняє їх за хвилину: якщо в JSON сума правильна — фронт, якщо ні — бекенд.
• Четвертий рядок — не баг у звичному сенсі. Код відповідає вимогам, але задачу бізнесу не розв'язує. Саме такі знахідки — легітимний результат приймального рівня, і заводити їх треба як питання до вимог, а не як дефект розробнику.
• Багато знахідок нижніх рівнів на UAT — окремий сигнал. Якби всі чотири проблеми знайшла бухгалтерія на прийманні, це означало б, що модульний, інтеграційний і системний рівні не спрацювали: на UAT легітимна лише четверта.

Кейс 2. «Це покрито модульними тестами» — що лишається в ручному чеклисті

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

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

• Перед прогоном подивись на сам PR. Зелені модульні тести — мінімальна гігієна білда; червоні — привід не починати ручний прогін узагалі, бо тестуватимеш свідомо зламаний білд.
• «Покрито модульними тестами» звужує, а не скасовує ручну роботу. Фокус зміщується туди, куди модульні тести не дістають: інтеграція, UI, реальні дані, наскрізні сценарії. Це і є практичне застосування рівнів: не перевіряти на своєму рівні те, що вже спіймано нижче.
• Довіряй, але дивись, що саме покрито. «Покрито модульними тестами» без переліку кейсів — не аргумент: спитати «а межа 999/1000 там є?» дешевше, ніж пропустити дефект на порозі знижки.

Кейс 3. Контракт на стику: інтеграційна перевірка через API

Сервіс замовлень віддає дату доставки сервісу нотифікацій. Обидва сервіси зелені на своїх модульних тестах, але листи приходять з датою «11 липня» замість «7 листопада»: контракт стику вимагає ISO 8601 (2026-11-07), замовлення шлють 07/11/2026 (день/місяць), а нотифікації парсять це як американський MM/DD/YYYY. Дефект живе рівно на стику — і перевіряється без UI, дешевим API-тестом:

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

test('контракт: дата доставки — ISO 8601, сума — в копійках', async ({ request }) => {
  const res = await request.get('/api/orders/12345');
  expect(res.status()).toBe(200);

  const order = await res.json();
  // контракт стику: YYYY-MM-DD, а не DD/MM чи MM/DD
  expect(order.deliveryDate).toMatch(/^\d{4}-\d{2}-\d{2}$/);
  // контракт стику: ціле число копійок, не рядок і не дробові гривні
  expect(Number.isInteger(order.totalAmount)).toBe(true);
});

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

• Об'єкт тесту — контракт, а не логіка. Тест не перевіряє, чи правильно порахована знижка (це модульні тести) і чи гарний лист (це системний рівень) — лише формат даних на стику. Падіння такого тесту одразу каже «зламано контракт», без пошуку по всій системі.
• Це і є альтернатива big bang у мініатюрі. Перевірити одне з'єднання окремо дешевше, ніж збирати все й дивитись на дивну дату в листі: локалізація миттєва, бо перевіряється рівно один стик.
• Якщо друга сторона стику зовнішня (платіжний провайдер, поштовий сервіс) — це вже системна інтеграція (system integration) за ISTQB 4.0: контракт той самий, але чужу сторону не полагодиш, тож тест ще й документує, на яку саме поведінку зовнішньої системи ви розраховуєте.
• Такий тест — регресійна страховка стику. Рефакторинг будь-якого з сервісів, який тихо змінить формат, впаде тут, а не в продакшен-листах: саме так інтеграційний рівень ловить свій клас дефектів раніше за системний.

Карта рівнів

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

Модульний рівень

• Розумію, що unit-тест перевіряє найменшу частину коду в ізоляції, а залежності (база, мережа) підмінюються стабами.
• Знаю головну силу рівня: мілісекунди на прогін, без середовища, точна локалізація — впав тест функції, дефект у функції.
• Можу пояснити, навіщо unit-покриття мануальному QA: не дублювати перевірки руками, тріажити баги за рівнями, читати сигнали якості білда (червоні модульні тести — не починати прогін).

Інтеграційний рівень

• Розумію, що інтеграційний рівень перевіряє взаємодію — контракти, формати даних, послідовності викликів, обробку помилок на стиках, — а не модулі повторно.
• Можу навести приклад дефекту, якого не видно всередині жодного модуля: копійки vs гривні, ISO-дата vs американський формат.
• Знаю три підходи до збирання і ціну кожного: big bang — пошук дефекту по всій системі, top-down — потрібні стаби, bottom-up — потрібні драйвери; на практиці інтегрують інкрементно — одне з'єднання за раз дає миттєву локалізацію.
• Можу пояснити різницю stub vs driver: стаб імітує нижній модуль і відповідає на виклики, драйвер імітує верхній рівень і сам викликає.

Системний і приймальний рівні

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

V-модель і відповідальність

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