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

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

    Види тестування: класифікація

    Зміст

    «Які види тестування ви знаєте?» — чи не найпередбачуваніше питання співбесіди на trainee/junior QA. І саме на ньому кандидати найчастіше сипляться: перелічують завчений список із двадцяти назв, плутають рівні з видами, а на уточнення «чим exploratory відрізняється від ad-hoc?» відповідають «ну… нічим?». Інтервʼюер перевіряє не памʼять, а систему в голові: чи розумієш ти, що види тестування — це не плаский список, а кілька незалежних осей, за якими можна розкласти будь-яку перевірку.

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

    Осі, а не список

    Рівні тестування відповідають на питання «де в життєвому циклі ми перевіряємо»: компонентне, інтеграційне, системне, приймальне. Види відповідають на інше питання — «що саме і з якого кута ми перевіряємо». Силабус ISTQB CTFL 4.0 (розділ 2.2.2) називає чотири базові види: функціональне, нефункціональне, black-box і white-box — і окремо підкреслює, що будь-який вид можна виконувати на будь-якому рівні.

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

    Фіча «Логін»

    Вісь: мета перевірки

    Вісь: знання внутрішньої будови

    Вісь: ступінь підготовки

    Вісь: спосіб виконання

    Функціональне

    Нефункціональне

    Black-box

    Grey-box

    White-box

    Скриптоване

    Exploratory

    Ad-hoc

    Мануальне

    Автоматизоване

    Фіча «Логін»

    Вісь: мета перевірки

    Вісь: знання внутрішньої будови

    Вісь: ступінь підготовки

    Вісь: спосіб виконання

    Функціональне

    Нефункціональне

    Black-box

    Grey-box

    White-box

    Скриптоване

    Exploratory

    Ad-hoc

    Мануальне

    Автоматизоване

    Осі незалежні, тож комбінуються вільно: негативна перевірка логіну може бути мануальною exploratory black-box сесією, а може — автоматизованим скриптованим grey-box тестом. Саме тому «список видів» неможливо вивчити вичерпно — а от чотири-пʼять осей тримаються в голові легко. До того ж вичерпне тестування неможливе в принципі, тому осі — це ще й спосіб свідомо вибрати, куди дивитися, а куди цього разу ні.

    Функціональне vs нефункціональне

    Функціональне тестування (functional testing) перевіряє, що система робить: чи відповідає її поведінка вимогам. Нефункціональне (non-functional testing) — наскільки добре вона це робить: швидкість, стійкість, безпека, зручність, сумісність. Класифікацію нефункціональних характеристик якості дає стандарт ISO/IEC 25010 — саме на нього посилається і силабус ISTQB.

    На прикладі логіну:

    КутПеревірка
    ФункціональнаВалідна пара email/пароль пускає в кабінет; невалідна — показує помилку; «забув пароль» надсилає лист
    НефункціональнаФорма відповідає швидко під навантаженням; пароль зберігається хешованим; логін працює в Safari і з клавіатури

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

    Black-box, white-box і grey-box

    Ця вісь — про те, скільки тестувальник знає про внутрішню будову системи і звідки бере тестові ідеї.

    • Black-box («чорна скринька») — ідеї беруться з вимог і зовнішньої поведінки; код невидимий. Сюди належать специфікаційні техніки тест-дизайну: класи еквівалентності, граничні значення (детально — в розділі «Тест-дизайн»).
    • White-box («біла/прозора скринька») — ідеї беруться зі структури коду: покрити всі гілки, всі умови. Зазвичай територія розробників і SDET; вимірюється покриттям коду.
    • Grey-box — часткове знання. Ти тестуєш через UI, але знаєш схему бази, читаєш логи, бачиш запити в мережевій панелі — і завдяки цьому будуєш точніші перевірки.

    Приклад grey-box: перевіряєш реєстрацію через форму (black-box кут), але після сабміту заглядаєш у базу і бачиш, що пароль лежить у відкритому вигляді. Через UI цей дефект невидимий у принципі. Ріст із manual QA в AQA — це значною мірою рух уздовж цієї осі: чим більше розумієш, як воно влаштоване всередині, тим дешевше знаходиш глибокі баги.

    Позитивні й негативні перевірки

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

    Ключовий нюанс, на якому ловлять на співбесідах: негативний тест вважається пройденим, коли система коректно відхилила сміття. Якщо форма мовчки прийняла email без «@» — негативний тест упав.

    Для поля email негативних ідей завжди більше, ніж позитивних: порожній рядок, пробіли, відсутній «@», два «@», 300 символів, кирилиця в домені, emoji, HTML-теги. Користувачі роблять неочікуване постійно, тому значна частина продакшн-багів живе саме на негативних сценаріях — а кандидати на співбесідах стабільно називають три позитивні перевірки і зупиняються.

    Обидва типи перевірок однаково добре автоматизуються — аби оракул був чіткий (приклад потребує основ JS/TS; можна пропустити без втрати змісту):

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

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

test('невалідний пароль дає зрозумілу помилку, а не 500', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Пароль').fill('wrong');
  await page.getByRole('button', { name: 'Увійти' }).click();
  await expect(page.getByRole('alert')).toContainText('Невірний email або пароль');
});

    Скриптоване, exploratory та ad-hoc

    Ця вісь — про те, скільки дизайну тестів відбувається до виконання.

    АспектСкриптованеExploratoryAd-hoc
    Дизайн тестівЗаздалегідь, у кейсахПід час виконанняНемає
    ДокументаціяТест-кейси/чеклистиЧартер + нотатки сесіїНемає
    ВідтворюваністьВисокаСередня (по нотатках)Низька
    Коли доречнеРегресія, приймання, аудитНова фіча, пошук нетипових багівШвидко «потикати» після дрібного фіксу

    Скриптоване (scripted) тестування — перевірки спроєктовані заздалегідь: кроки, дані, очікуваний результат. Плюси: відтворюваність, передаваність, слід для аудиту. Мінус: знаходить лише те, що хтось передбачив.

    Дослідницьке (exploratory) тестування — одночасне вивчення продукту, дизайн і виконання тестів. Це не хаотичне тикання: сесійний підхід дає чартер («дослідити імпорт CSV з кута невалідних кодувань»), таймбокс (зазвичай 60–120 хвилин), нотатки і дебриф. Канонічний розбір — окрема глава в розділі «Тест-дизайн»; тут достатньо запамʼятати межу.

    Ad-hoc — перевірка без структури й документації: сів, потикав, пішов далі. Найдешевший спосіб зловити очевидне і цілком легітимний у своїй ніші — але результат не відтворити і не передати.

    Межа між exploratory і ad-hoc — улюблене питання-фільтр на співбесідах: чартер, таймбокс і нотатки перетворюють одне на інше.

    Нефункціональні види: короткий огляд

    Кожен із цих видів — окрема дисципліна з власним інструментарієм; тут — рівно стільки, скільки треба для системної картини і співбесіди trainee.

    Продуктивність (performance testing). Вимірює час відповіді, пропускну здатність і споживання ресурсів. Класичні підвиди: навантажувальне (load) — поведінка під очікуваним навантаженням; стресове (stress) — за межею очікуваного, шукаємо точку відмови і те, як система деградує; spike — різкий стрибок трафіку; endurance/soak — тривала робота, полювання на витоки памʼяті.

    Безпека (security testing). Перевіряє захищеність даних і функцій: автентифікацію й авторизацію, стійкість до інʼєкцій, витоки чутливих даних. Загальновживаний орієнтир — OWASP Top 10, оновлюваний раз на кілька років перелік найкритичніших ризиків безпеки вебзастосунків. Мінімум, який має помічати кожен QA: паролі й токени в URL чи логах, доступ до чужих даних простою підміною id у запиті.

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

    Usability: евристики Нільсена

    Тестування зручності використання (usability testing) відповідає на питання: чи можуть реальні користувачі досягати своїх цілей результативно, ефективно і з задоволенням. Два основні інструменти: спостереження за користувачами, які виконують реальні задачі, та евристична оцінка (heuristic evaluation) — експертний прохід інтерфейсом за списком перевірених принципів.

    Найвідоміший такий список — 10 евристик Якоба Нільсена (Jakob Nielsen, 1994):

    1. Видимість статусу системи — користувач завжди розуміє, що відбувається (спінер, прогрес, підтвердження).
    2. Відповідність системи реальному світу — мова користувача, а не жаргон розробників.
    3. Контроль і свобода користувача — є «аварійний вихід»: скасувати, повернутись.
    4. Послідовність і стандарти — однакові речі виглядають і поводяться однаково.
    5. Запобігання помилкам — краще не дати помилитись, ніж гарно повідомити про помилку.
    6. Впізнавання замість пригадування — опції видно, а не треба тримати в голові.
    7. Гнучкість та ефективність — новачку просто, досвідченому швидко (шорткати, історія).
    8. Естетичний і мінімалістичний дизайн — нічого зайвого, що конкурує за увагу.
    9. Допомога в розпізнаванні й виправленні помилок — повідомлення пояснює, що сталося і що робити, а не «Error 0x80004005».
    10. Довідка й документація — доступна, конкретна, по задачі.

    QA рідко проводить повноцінні usability-дослідження, але евристики — готова мова для баг-репортів про UX: замість субʼєктивного «незручно» пишеш «порушена видимість статусу: після кліку "Зберегти" три секунди жодної реакції — користувач клікає повторно і створює дублікат».

    Локалізація vs інтернаціоналізація

    Пара термінів, яку плутають найчастіше. Інтернаціоналізація (internationalization, i18n) — проєктування продукту так, щоб адаптацію під різні мови й регіони було можливо зробити без переписування коду. Локалізація (localization, l10n) — сама адаптація під конкретну локаль. Числа в скороченнях — кількість літер між першою й останньою в англійському слові.

    i18nl10n
    Що цеГотовність до адаптаціїАдаптація під конкретну локаль
    Хто робитьРозробники, архітектураПерекладачі, LQA-тестувальники
    Приклади робітРядки винесені з коду, підтримка Unicode, гнучкі шаблони дат/чиселПереклад, формати дат/валют, культурні норми, юридичні тексти
    Що тестуємоПсевдолокалізація, введення не-латиниці, перемикання локаліПереклад у контексті UI, обрізання, коректність форматів

    i18n тестується до перекладу — зокрема псевдолокалізацією: рядки замінюють подовженими з діакритикою (щось на кшталт [!!! Àççôûñţ Šéţţîñĝš !!!]), і одразу видно захардкоджені тексти й верстку, яка не переживе довших слів. l10n тестується після: переклад у контексті (а не в таблиці рядків), формати — 1,000.50 проти 1 000,50, 07/16/2026 проти 16.07.2026, валюта і напрямок письма (RTL для арабської та івриту), німецькі складені слова, що розносять кнопки.

    Доступність (accessibility, a11y): оглядово

    Тестування доступності перевіряє, чи можуть продуктом користуватися люди з порушеннями зору, слуху, моторики чи когнітивними особливостями. Канонічний стандарт — WCAG (Web Content Accessibility Guidelines) від W3C: чотири принципи (сприйманість, керованість, зрозумілість, надійність — POUR) і три рівні відповідності A/AA/AAA, де AA — типова ціль команд і законодавств.

    Мінімальний набір перевірок, доступний кожному QA без спецпідготовки: пройти ключовий сценарій лише з клавіатури (фокус видно? нічого не «застрягло»?), перевірити alt-тексти зображень, контраст тексту, звʼязку полів форми з підписами. Автоматичні сканери ловлять лише частину проблем — решта вимагає ручної перевірки, в ідеалі зі скрінрідером. Важливо розуміти й мотивацію: у багатьох юрисдикціях доступність — вимога закону, а не «nice to have». Детальний розбір — в окремій главі розділу про веб.

    Мануальне vs автоматизоване

    Остання вісь — хто виконує перевірку. Правильне питання тут не «що краще», а «яку перевірку дешевше й надійніше виконувати як».

    Автоматизація сильна там, де перевірка часта, стабільна і має чіткий оракул — очікуваний результат, який можна порівняти програмно. Тому регресія — перший кандидат на автоматизацію: ті самі перевірки, кожен реліз, відомий результат. Людина незамінна там, де оракул нечіткий: exploratory, usability, «щось тут виглядає дивно». Корисна рамка: автоматизація виконує перевірки (checks) — порівняння з очікуванням; людина виконує тестування — дослідження і судження про якість.

    І памʼятай, що автоматизація — інвестиція: тест треба написати, а потім підтримувати при кожній зміні продукту. Автоматизувати одноразову перевірку — збиток; не автоматизувати тисячну регресію — теж.

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

    • Виглядає як «нефункціональне — другорядне, потестуємо після релізу», а насправді нефункціональні дефекти найчастіше архітектурні: падіння під навантаженням не лікується патчем за вечір і коштує найдорожче саме тому, що знайдене пізно.
    • Виглядає як «негативний тест — це тест, який падає», а насправді негативний тест проходить, коли система коректно відхилила невалідний вхід; падає він тоді, коли система мовчки прийняла сміття.
    • Виглядає як «exploratory — це коли тикаєш без плану», а насправді без чартера, таймбокса й нотаток це ad-hoc; exploratory — дисциплінована техніка з артефактами.
    • Виглядає як «black-box означає, що в код і БД дивитися заборонено», а насправді це лише джерело тестових ідей; заглянути в базу чи логи — перейти в grey-box і зловити те, що через UI невидиме.
    • Виглядає як «локалізація — це переклад», а насправді це ще формати дат, чисел і валют, сортування, RTL, довжина рядків у верстці й культурний контекст; переклад — лише перший пункт чеклиста.
    • Виглядає як «автоматизуємо все — і мануальне тестування не потрібне», а насправді автоматизація перевіряє відоме, а нові баги здебільшого живуть там, де сценарію ще не існує.

    Підсумок

    • Види тестування — незалежні осі (мета, знання внутрішньої будови, ступінь підготовки, спосіб виконання), а не плаский список; одна перевірка має координату на кожній осі, і будь-який вид застосовний на будь-якому рівні.
    • Функціональне — «що робить система», нефункціональне — «наскільки добре»; нефункціональні вимоги зазвичай неписані, і їх треба явно виявляти й формулювати перевірюваними.
    • Негативні перевірки — обовʼязкова половина тест-дизайну: система має контрольовано відхиляти невалідний вхід, і саме там живе значна частина продакшн-багів.
    • Exploratory відрізняється від ad-hoc наявністю чартера, таймбокса й нотаток — це керована техніка, а не хаотичне тикання.
    • Автоматизація забирає часті перевірки з чітким оракулом (регресію передусім); дослідження, usability і судження про якість лишаються за людиною.

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

    Типові формулювання:

    • «Які види тестування ви знаєте?» — чекають не на список, а на структуру: назви осі, дай по прикладу на кожну.
    • «Чим функціональне тестування відрізняється від нефункціонального? Приклади для однієї фічі.» — перевіряють, чи бачиш обидва кути на одному обʼєкті.
    • «Що таке grey-box? Наведіть приклад.» — сильна відповідь містить конкретику: перевірка запису в БД, читання логів, мережева панель.
    • «Чим exploratory відрізняється від ad-hoc?» — питання-фільтр; згадай чартер, таймбокс, нотатки.
    • «Наведіть негативні перевірки для поля дати народження.» — дивляться, чи не зупинишся на трьох очевидних (майбутня дата, порожнє поле, 30 лютого, вік 150 років, невідповідний формат, вставка тексту).
    • «Що б ви автоматизували в першу чергу і чому?» — перевіряють розуміння регресії, повторюваності й ціни підтримки, а не любов до інструментів.
    • «Чим локалізація відрізняється від інтернаціоналізації?» — плюс уточнення, що саме перевіряти в кожній.

    Інтервʼюер дивиться на три речі: чи є система (осі замість завченого переліку), чи є конкретика (приклади з реальних фіч, а не означення з підручника) і чи розумієш межі (де автоматизація не окупиться, де black-box недостатньо, коли ad-hoc — нормальний вибір).

    Джерела