Техніки тест-дизайну: від теорії до практики. Частина 1

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

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

Мене звати Дмитро, я інженер із забезпечення якості (QA Engineer) у компанії GlobalLogic. Мій шлях у тестуванні розпочався з позиції trainee, і вже понад шість років я працюю у сфері якості ПЗ. За цей час я неодноразово виступав ментором для новачків, а також ділився досвідом як лектор і ментор на внутрішніх навчальних програмах компанії.

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

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

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

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

Що таке тест-дизайн та його роль у забезпеченні якості ПЗ

Як визначити, що програмний продукт справді якісний? Чи можливо перевірити всі сценарії його роботи? На жаль, це майже неможливо — повне тестування потребувало б надто багато часу, ресурсів і зусиль. Саме тому тестувальники не тестують усе підряд, а застосовують спеціальні підходи, що допомагають оптимізувати процес.

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

Згідно з ISTQB (International Software Testing Qualifications Board), тест-дизайн — це процес створення та визначення тестових умов, тестових випадків і тестових процедур. Іншими словами, це крок у тестуванні, який дозволяє вирішити, що саме потрібно перевірити, які вхідні дані використовувати і як оцінювати результати.

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

Чому важливо використовувати техніки тест-дизайну

Техніки тест-дизайну (Test Design Techniques) — це систематизовані методи створення тест-кейсів, які дозволяють зосередитись на найважливіших ділянках функціоналу та виявляти дефекти навіть у складних або неочевидних сценаріях. Вони допомагають уникнути хаотичного підходу до перевірки й дозволяють досягати максимальної ефективності без надмірних витрат.

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

Згідно з ISTQB, використання технік тест-дизайну дозволяє:

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

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

Взаємозв’язок тест-дизайну з тестуванням програмного забезпечення

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

Згідно з ISTQB, тест-дизайн є одним із ключових етапів життєвого циклу тестування. Він входить у фазу підготовки тестів, де тестувальники аналізують вимоги, визначають, які тестові випадки необхідні, та обирають відповідні техніки для їх створення.

Без тест-дизайну тестувальники можуть:

  • Пропустити важливі сценарії тестування.
  • Витратити час на зайві перевірки.
  • Не помітити критичні дефекти до виходу продукту.

Саме тому тест-дизайн є невіддільним від тестування — він визначає, наскільки добре тестування виконає свою функцію.

Загальні принципи та цілі тест-дизайну

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

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

Цілі тест-дизайну

  1. Виявлення дефектів: основною метою є виявлення помилок у програмному забезпеченні на ранніх етапах, щоб усунути їх до того, як продукт потрапить до кінцевих користувачів.
  2. Перевірка функціональності: переконатися, що система працює відповідно до вимог, і всі функції виконуються належним чином.
  3. Покриття всіх можливих сценаріїв: створення тестів, які охоплюють всі можливі варіанти використання системи, включаючи позитивні, негативні та граничні умови.
  4. Забезпечення якості продукту: забезпечити належну якість програмного забезпечення, перевіряючи його функціональні та нефункціональні характеристики, як от продуктивність, безпека, зручність користування тощо.
  5. Мінімізація ризиків: визначення та тестування критичних частин системи для мінімізації ризиків, пов’язаних із її використанням у реальних умовах.
  6. Оптимізація процесу тестування: забезпечення того, щоб тестування було ефективним і мало мінімальні витрати часу і ресурсів, при цьому гарантуючи достатній рівень покриття.

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

Використовуючи правильні техніки тест-дизайну, можна не тільки зекономити час і ресурси, а й значно покращити якість кінцевого продукту. У наступних розділах ми розглянемо, які саме техніки існують і як їх застосовувати на практиці.

Класифікація технік тест-дизайну

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

Статичні техніки тестування (Static Testing Techniques)

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

  • Аналіз вимог (Requirements Analysis) — процес перевірки специфікацій та вимог на їхню узгодженість, повноту та відповідність очікуванням користувачів. Використовується для запобігання логічним суперечностям та помилкам ще до розробки коду.
  • Рецензування (Peer Review, Walkthrough, Inspection) — оцінка документації, тест-кейсів або вихідного коду шляхом групового аналізу. Це дозволяє виявити потенційні помилки за допомогою експертної оцінки інших учасників команди.
  • Статичний аналіз коду (Static Code Analysis) — використання автоматизованих інструментів для перевірки вихідного коду на наявність потенційних дефектів, таких як порушення стандартів кодування, вразливості безпеки, надлишкова складність тощо.

Згідно з ISTQB, статичне тестування є ефективним методом виявлення дефектів ще до запуску коду. Воно дозволяє зменшити витрати на подальше виправлення помилок та покращити якість кінцевого продукту.

Динамічні техніки тестування (Dynamic Testing Techniques)

Динамічне тестування передбачає виконання програмного коду для аналізу його поведінки та відповідності очікуваним результатам. Цей підхід дозволяє перевіряти роботу системи в реальних умовах. Основні методи:

  • Функціональне тестування (Functional Testing) — перевіряє, чи відповідає програмне забезпечення визначеним функціональним вимогам. Використовується для перевірки коректності обробки вхідних даних, логіки бізнес-процесів та відповідності очікуваним виходам.
  • Нефункціональне тестування (Non-functional Testing) — аналіз характеристик системи, які не пов’язані безпосередньо з її функціональністю, таких як продуктивність, безпека, зручність використання та стійкість до навантажень.
  • Структурні підходи (Structural Testing Approaches) — тестування внутрішньої архітектури та логіки програми, наприклад, покриття операторів, гілок або шляхів виконання. Цей метод дозволяє оцінити, наскільки добре код охоплений тестами.

Відповідно до стандартів ISTQB, динамічне тестування є критично важливим для перевірки фактичної поведінки системи, що дає змогу оцінити її відповідність вимогам та знаходити дефекти у процесі виконання.

Чорна скринька (Black-box Testing)

Методи чорної скриньки зосереджуються на тестуванні функціональності програмного забезпечення без урахування його внутрішньої реалізації. Тестувальники працюють із вхідними даними та аналізують вихідні результати. Основні техніки:

  • Аналіз еквівалентних класів (Equivalence Partitioning) — поділ вхідних даних на групи, у межах яких система повинна поводитися однаково.
  • Аналіз граничних значень (Boundary Value Analysis) — перевірка роботи системи на межах допустимих діапазонів вхідних даних, де найчастіше трапляються помилки.
  • Таблиці прийняття рішень (Decision Table Testing) — побудова таблиці можливих комбінацій вхідних умов і відповідних очікуваних виходів для перевірки логіки обробки даних.
  • Метод випадків використання (Use Case Testing) — тестування на основі сценаріїв взаємодії користувача із системою для перевірки відповідності очікуваним бізнес-процесам.

Біла скринька (White-box Testing)

Методи білої скриньки дозволяють тестувальникам аналізувати внутрішню структуру програмного коду, що дає змогу перевірити логіку роботи програми на низькому рівні. Основні техніки:

  • Аналіз покриття коду (Code Coverage Analysis) — визначає відсоток вихідного коду, який виконується під час тестування (наприклад, покриття операторів, умов або гілок коду).
  • Тестування потоків даних (Data Flow Testing) — аналіз використання змінних та їхнього стану в процесі виконання програми для виявлення помилок у логіці роботи з даними.
  • Мутаційне тестування (Mutation Testing) — внесення навмисних змін у код для перевірки ефективності тестів у виявленні помилок.

Додаткові підходи

До цього розділу можна додати такі аспекти:

  • Ризикорієнтоване тестування (Risk-based Testing) — визначення та тестування найбільш ризикованих частин системи для мінімізації потенційних збитків від дефектів.
  • Експлоративне тестування (Exploratory Testing) — дослідження програмного забезпечення без заздалегідь визначених тест-кейсів, що дозволяє знаходити несподівані помилки.
  • Тестування на основі моделей (Model-based Testing) — створення моделей системи, які використовуються для автоматичної генерації тестів.
  • Грей-бокс тестування (Gray-box Testing) — поєднання підходів чорної та білої скриньки, коли тестувальник має часткове знання внутрішньої реалізації.
  • Тестування відновлення (Recovery Testing) — перевірка здатності системи відновлюватися після відмови чи збоїв.
  • Тестування безперервності бізнесу (Business Continuity Testing) — оцінка стійкості системи в умовах критичних ситуацій, таких як відключення серверів або втрата даних.

Згідно з ISTQB, кожен із цих підходів має своє місце в процесі тестування і використовується залежно від цілей тестування, рівня ризиків і типу програмного забезпечення. Такий підхід до класифікації дозволяє ефективно організувати процес тестування та вибрати відповідні техніки залежно від поставлених цілей.

Розбір на практиці: Black Box техніки

Еквівалентне розбиття (Equivalence Partitioning, EP)

Визначення за ISTQB: Equivalence Partitioning — це техніка тест-дизайну, яка розділяє набір вхідних або вихідних значень на еквівалентні підмножини (класи), в межах яких програмне забезпечення повинно поводитися однаково.

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

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

Простий приклад: перевірка віку користувача

Система приймає вік у межах 18–60 включно. Усі інші значення — невалідні.

Клас

Опис

Приклад значення

Валідний клас

Вік від 18 до 60

30

Невалідний клас 1

Вік менше 18

17

Невалідний клас 2

Вік більше 60

61

Складніший приклад: перевірка логіна користувача

Вимоги:

  • Довжина — від 5 до 20 символів.
  • Дозволені символи: латинські літери, цифри, підкреслення.
  • Заборонено: початок з цифри або підкреслення; використання пробілів, кирилиці, спецсимволів (!, @, #, % тощо).

Клас

Опис

Приклад

Валідний клас

Відповідає всім вимогам

User_1

Невалідний клас 1

Коротший за 5 символів

adm1

Невалідний клас 2

Довший за 20 символів

averyveryverylonglogin

Невалідний клас 3

Починається з цифри

1admin

Невалідний клас 4

Починається з підкреслення

_user

Невалідний клас 5

Містить заборонені символи (пробіли, кирилиця, спецсимволи)

user!, адмін, admin name

Рекомендації:

  • Для кожного логічного класу достатньо одного представника.
  • Враховуйте формальні обмеження (довжина, набір символів) і семантичні правила (порядок символів).
  • Поєднуйте з BVA для повнішого охоплення.

Аналіз граничних значень (Boundary Value Analysis, BVA)

Визначення за ISTQB: Boundary Value Analysis — це техніка тест-дизайну, яка зосереджується на граничних значеннях вхідних змінних. Помилки найімовірніше виникають у цих точках.

Техніка дозволяє виявляти помилки, які пов’язані з неправильним трактуванням умов, типу >= замість >, або некоректним контролем за межами допустимого.

Доцільна при:

  • наявності числових або довжинних обмежень;
  • високій ймовірності помилок саме на межах;
  • потребі перевірки точного реагування на граничні значення.

Простий приклад: вік користувача

Система приймає вік від 18 до 60 включно.

Тип значення

Значення

Очікувана поведінка

Нижче мінімуму

17

Відхилено

Мінімум

18

Прийнято

Мінімум + 1

19

Прийнято

Максимум — 1

59

Прийнято

Максимум

60

Прийнято

Вище максимуму

61

Відхилено

Складніший приклад: довжина логіна

Вимоги: від 5 до 20 символів.

Тип значення

Кількість символів

Приклад

Очікувана поведінка

Нижче мінімуму

4

abcd

Відхилено

Мінімум

5

admin

Прийнято

Мінімум + 1

6

admin1

Прийнято

Максимум — 1

19

valid_user_2024max

Прийнято

Максимум

20

admin_user_length20

Прийнято

Вище максимуму

21

admin_user_too_long_1

Відхилено

Рекомендації:

  • Мінімум, максимум і значення поруч із ними — критичні.
  • Варто тестувати як всередині діапазону, так і на його межах.
  • Добре працює в поєднанні з EP, щоб охопити всі типові та граничні сценарії.

Техніки Equivalence Partitioning (EP) та Boundary Value Analysis (BVA) є основою ефективного тест-дизайну і доповнюють одна одну. Equivalence Partitioning допомагає вибрати мінімальний різноманітний набір тестів, що покривають всі типи вхідних даних, а Boundary Value Analysis гарантує, що крайні випадки (на межах цих типів) не призведуть до збоїв.

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

Тестування переходів станів (State Transition Testing)

State Transition Testing — це техніка тест-дизайну, яка дозволяє моделювати поведінку системи через зміну її внутрішніх станів. Її особливість полягає в тому, що вихід системи залежить не лише від поточного введення, а й від того, у якому стані знаходиться система під час цього введення.

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

Основні поняття (згідно ISTQB)

Щоб ефективно застосовувати техніку, слід розуміти базову термінологію:

  • Стан (State) — визначений набір умов або ситуацій системи у певний момент часу.
  • Подія (Event) — зовнішня дія або внутрішній тригер, що спричиняє потенційну зміну стану.
  • Перехід (Transition) — зміна одного стану на інший у відповідь на подію.
  • Дія (Action) — вихід або відповідь системи, що виникає в результаті переходу.

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

Уявімо ситуацію, коли користувач намагається зняти кошти в банкоматі. Якщо до цього система не зареєструвала вставлення картки або не була виконана верифікація PIN, така дія повинна бути забороненою. Саме такі залежностій контролює State Transition Testing.

Основні переваги (за ISTQB):

  • Покриття поведінки системи залежно від її історії.
  • Ефективне виявлення помилок логіки, недійсних переходів або відсутності очікуваних реакцій.
  • Простота візуалізації за допомогою діаграм станів.
  • Можливість використання для автоматизованого тестування (наприклад, за допомогою модельного тестування).

Простий приклад: кавовий автомат

У цьому прикладі автомат готує каву лише після того, як користувач вставив монету. Якщо натиснути кнопку до цього — автомат має вивести повідомлення про необхідність оплати.

Стан

Подія

Новий стан

Реакція системи

Очікує монету

Вставлено монету

Очікує вибір напою

Меню напоїв активне

Очікує монету

Натиснуто кнопку

Очікує монету

Повідомлення: «Вставте монету»

Очікує вибір напою

Обрано каву

Готує каву

Приготування та видача кави

Готує каву

Завершено видачу

Очікує монету

Повернення до початкового стану

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

Складніший приклад: банкомат

Система банкомата має більше станів і подій, що робить її цікавою для тестування технікою переходів станів.

Сценарій:

  1. Користувач вставляє картку (перевірка валідності).
  2. Вводить PIN (до 3 спроб).
  3. Вибирає операцію (баланс, зняття готівки).
  4. Завершує або повторює операцію.
  5. Забирає картку.

Стани:

  • S0: Очікує картку
  • S1: Картку вставлено
  • S2: Введення PIN
  • S3: Вибір операції
  • S4: Виконання
  • S5: Повернення картки

Події:

  • E1: Вставлено валідну/невалідну картку
  • E2: Введено правильний / неправильний PIN
  • E3: Вибір операції
  • E4: Завершення / відмова
  • E5: Забір картки

Поточний стан

Подія

Новий стан

Реакція / дія

S0

E1 (валідна картка)

S1

Запрошення до введення PIN

S0

E1 (невалідна картка)

S5

Відмова, повернення картки

S1

(Автоматично)

S2

Показ екрана вводу PIN

S2

E2 (PIN вірний)

S3

Меню операцій

S2

E2 (PIN невірний 1–2)

S2

Повідомлення: «Невірний PIN. Спробуйте ще»

S2

E2 (PIN невірний 3 рази)

S5

Блокування картки

S3

E3 (вибір операції)

S4

Обробка операції

S4

E4 (ще одна дія)

S3

Повернення до вибору

S4

E4 (завершити)

S5

Картка готується до повернення

S5

E5 (картка забрана)

S0

Повернення до стану очікування нового клієнта

Типи покриття (ISTQB):

  • Покриття станів — перевірка, що кожен стан був активований хоча б один раз.
  • Покриття переходів — кожен перехід між станами тестувався.
  • Покриття послідовностей переходів — перевірка важливих або критичних послідовностей переходів.

Наприклад, ISTQB радить для високоризикованих систем забезпечувати щонайменше повне покриття перехідних комбінацій, а не лише окремих станів чи одиничних переходів.

Коли техніка найбільш корисна?

  • Системи з пам’яттю: турнікети, замки, сейфи.
  • Банківські / фінансові транзакції.
  • Машини з продажу товарів.
  • Системи доступу з ролями.
  • Робота в обмежених режимах: обмеження кількості спроб, тайм-аути.

State Transition Testing — ефективний підхід для систем, у яких важлива послідовність подій. Він дозволяє точно змоделювати поведінку і протестувати не тільки «що» відбувається, але і «коли» це дозволено. Із точки зору ISTQB, ця техніка є частиною базових знань кожного тестувальника, особливо у сферах, де правильний порядок дій критичний для безпеки або фінансових операцій.

Таблиці прийняття рішень (Decision Table Testing)

Тестування з використанням таблиць прийняття рішень (Decision Table Testing) — це техніка тест-дизайну, яка дозволяє систематизувати комбінації вхідних умов і пов’язаних із ними дій або результатів. Особливо корисна в умовах складної логіки, де вихід залежить від кількох змінних.

Такий підхід широко використовується:

  • у валідації бізнес-правил;
  • в обробці транзакцій;
  • у модулях прийняття рішень, які використовують комбінації кількох умов (наприклад, кредитна політика, тарифи, бонуси тощо).

Простий приклад

Задача: rористувач має право отримати знижку, якщо:

  • він є постійним клієнтом ©;
  • або замовляє на суму понад 1000 грн (A).

Результат: надати знижку (Yes) або не надавати (No).

Condition

Rule 1

Rule 2

Rule 3

Rule 4

Regular customer ©

No

Yes

No

Yes

Order amount > 1000 UAH (A)

No

No

Yes

Yes

Action: Apply discount

No

Yes

Yes

Yes

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

Тест-кейси на основі таблиці прийняття рішень:

TC ID

Regular customer ©

Order amount > 1000 UAH (A)

Expected Result

TC01

No

No

Discount not applied

TC02

Yes

No

Discount applied

TC03

No

Yes

Discount applied

TC04

Yes

Yes

Discount applied

Складніший приклад

Задача: верифікація кредитної заявки залежно від трьох умов:

  • Позичальник має стабільний дохід (Income).
  • Позичальник не має боргів (No Debt).
  • Позичальник має позитивну кредитну історію (Credit History).

Дія: прийняти заявку (Approved — A) або відхилити заявку (Rejected — R)

Condition

R1

R2

R3

R4

R5

R6

R7

R8

Stable income (Income)

Yes

Yes

Yes

Yes

No

No

No

No

No debt (No Debt)

Yes

Yes

No

No

Yes

Yes

No

No

Positive credit history (Credit History)

Yes

No

Yes

No

Yes

No

Yes

No

Action: Decision

A

R

R

R

R

R

R

R

  • Заявка схвалюється (A) лише в тому випадку, коли всі три умови виконані.
  • Усі інші комбінації призводять до відмови (R), оскільки хоча б одна з критичних умов не виконується.

Тест-кейси на основі таблиці прийняття рішень:

TC ID

Income

No Debt

Credit History

Expected Decision

TC01

Yes

Yes

Yes

Approved

TC02

Yes

Yes

No

Rejected

TC03

Yes

No

Yes

Rejected

TC04

Yes

No

No

Rejected

TC05

No

Yes

Yes

Rejected

TC06

No

Yes

No

Rejected

TC07

No

No

Yes

Rejected

TC08

No

No

No

Rejected

При побудові тест-кейсів за таблицею прийняття рішень слід: визначити всі релевантні умови (inputs), що впливають на поведінку системи; встановити всі можливі комбінації вхідних умов; описати очікувані дії/виходи (outputs) для кожної комбінації; спростити таблицю, об’єднавши однакові результати, якщо це можливо (опціонально); створити окремий тест-кейс для кожного унікального правила.

Техніка Decision Table Testing забезпечує повне покриття логіки прийняття рішень, що особливо корисно в системах із багатьма умовами та складними залежностями. Вона дозволяє уникати логічних помилок, покривати всі суттєві варіанти сценаріїв, формалізувати вимоги у вигляді таблиць. Цей метод підходить як для автоматизованого, так і для ручного тестування, і часто використовується у банківських, фінансових, страхових системах.

Комбінаторне тестування, парне тестування (Pairwise Testing)

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

Одним із найвідоміших підходів до комбінаторного тестування є парне тестування (Pairwise Testing). Воно базується на дослідженнях, які показали, що більшість помилок у ПЗ викликаються взаємодією не більше ніж двох параметрів одночасно. Це дозволяє зменшити кількість тестів, забезпечивши при цьому достатній рівень покриття.

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

  • Кількість комбінацій параметрів зростає експоненційно (т.зв. combinatorial explosion).
  • Відомо, що більшість помилок виникають у взаємодії 2-х параметрів.
  • Потрібно зменшити кількість тест-кейсів без втрати ефективності.

Основна перевага: значне зменшення кількості тестів без істотного зниження якості тестування.

Згідно з дослідженнями NIST (National Institute of Standards and Technology), понад 70% дефектів спричиняються взаємодією лише двох параметрів. Це стало підґрунтям для активного використання Pairwise Testing у промисловому тестуванні.

Як побудувати парне тестування вручну (без інструментів)

Припустимо, маємо 3 параметри:

  • Браузер (Browser): Chrome, Firefox
  • ОС (Operating System): Windows, macOS
  • Тип входу (Login Type): Пароль, Біометрія

Загальна кількість повних комбінацій: 2 × 2 × 2 = 8

Але для парного покриття достатньо 4-х тестів, якщо підібрати їх грамотно.

TC

Browser

OS

Login Type

1

Chrome

Windows

Пароль

2

Chrome

macOS

Біометрія

3

Firefox

Windows

Біометрія

4

Firefox

macOS

Пароль

Ці 4 тест-кейси покривають усі можливі пари значень між параметрами.

Пара параметрів

Усі можливі пари значень

Browser × OS

Chrome + Windows, Chrome + macOS, Firefox + Windows, Firefox + macOS

Browser × Login

Chrome + Пароль, Chrome + Біометрія, Firefox + Пароль, Firefox + Біометрія

OS × Login

Windows + Пароль, Windows + Біометрія, macOS + Пароль, macOS + Біометрія

Побудова тест-кейсів (за допомогою pairwise-алгоритму)

Розглянемо систему, яка обробляє заявку на відкриття рахунку в банку. Є чотири параметри:

  • Тип клієнта (Customer Type): Фізична особа, Юридична особа.
  • Громадянство (Citizenship): Резидент, Нерезидент.
  • Тип рахунку (Account Type): Поточний, Депозитний.
  • Канал подачі заявки (Application Channel): Онлайн, У відділенні.

Повна таблиця всіх комбінацій містить: 2 × 2 × 2 × 2 = 16 комбінацій. Замість повного перебору застосуємо парне тестування.

У випадках, коли параметрів багато (4 і більше), доцільно використовувати спеціалізовані інструменти, які автоматично формують набір тестів з повним парним покриттям. Це знижує ризик помилки й економить час.

Популярні інструменти для генерації pairwise-комбінацій:

Згенеровані тест-кейси (приклад)

ID

Customer Type

Citizenship

Account Type

Application Channel

1

Фізична особа

Резидент

Поточний

Онлайн

2

Юридична особа

Резидент

Депозитний

Онлайн

3

Фізична особа

Нерезидент

Депозитний

У відділенні

4

Юридична особа

Нерезидент

Поточний

У відділенні

5

Юридична особа

Резидент

Поточний

У відділенні

6

Фізична особа

Нерезидент

Поточний

Онлайн

Покриття пар:

  • Customer × Citizenship
  • Customer × Account
  • Customer × Channel
  • Citizenship × Account
  • Citizenship × Channel
  • Account × Channel

Pairwise Testing дозволяє зменшити кількість тестів з експоненційного до лінійного рівня, зберігаючи покриття найчастіших дефектів. Ручна побудова можлива для 2–3 параметрів, але при 4+ параметрах рекомендовано використовувати генератори. Техніка особливо ефективна при тестуванні форм, конфігурацій, систем з численними налаштуваннями або варіантами. Варто комбінувати Pairwise із Boundary Value Analysis, Decision Table Testing та іншими техніками. Для більш критичних систем замість 2-wise (Pairwise) варто застосовувати 3-wise або 4-wise тестування, n-wise testing — забезпечує більше покриття, але й більшу кількість тестів.

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

Порівняння з Decision Table Testing:

Критерій

Pairwise Testing

Decision Table Testing

Підходить для

Багатьох параметрів

Умов і правил з логічною залежністю

Основна мета

Покриття комбінацій значень

Виявлення всіх комбінацій умов і результатів

Логічна складність

Низька—середня

Висока (правила, залежності)

Автоматизація

Легко автоматизується

Потребує логічної побудови вручну

Тестування сценаріїв використання (Use Case Testing)

Техніка Use Case Testing базується на аналізі сценаріїв використання (use cases), які описують взаємодію користувача (акторів) із системою для досягнення певної цілі. Цей підхід особливо корисний при тестуванні функціональності системи з точки зору кінцевого користувача, тому є ефективним як на рівні системного, так і приймального тестування. Сценарії використання зазвичай моделюють типову поведінку (основний сценарій) і варіанти (альтернативні шляхи), які виникають при помилках, винятках або інших умовах.

Основні переваги:

  • Охоплення важливих з точки зору бізнесу процесів.
  • Можливість виявлення відхилень у поведінці системи.
  • Добре підходить для побудови тест-кейсів з урахуванням умов, дій користувача та очікуваних результатів.

Ця техніка ефективна, коли:

  • Є наявні специфікації у вигляді сценаріїв використання або UML-діаграм.
  • Потрібно протестувати взаємодію системи з користувачем.
  • Важливо забезпечити правильну реалізацію бізнес-процесів.
  • Продукт має критичне значення для кінцевих користувачів (наприклад, банківські застосунки, онлайн-магазини тощо).

Простий приклад

Контекст: сценарій авторизації користувача в системі.

  • Сценарій використання: «Успішний вхід до системи».
  • Актор: Зареєстрований користувач.
  • Передумови: Користувач має обліковий запис.
  • Основний сценарій:
  1. Користувач відкриває форму входу.
  2. Вводить логін і пароль.
  3. Натискає кнопку «Увійти».
  4. Система перевіряє дані.
  5. Система надає доступ до особистого кабінету.

Альтернативний сценарій (помилковий пароль): 4a. Система виводить повідомлення: «Невірний логін або пароль».

Тест-кейси:

ID

Вхідні дані

Очікуваний результат

TC01

Правильний логін і пароль

Доступ до кабінету

TC02

Правильний логін, неправильний пароль

Повідомлення про помилку

TC03

Порожні поля

Повідомлення: «Заповніть обидва поля»

Складніший приклад

Контекст: Сценарій оформлення замовлення в інтернет-магазині.

  • Сценарій використання: «Оформлення покупки»
  • Актор: Покупець
  • Передумови: Товари в кошику, користувач авторизований
  • Основний сценарій:
  1. Користувач відкриває кошик.
  2. Натискає «Оформити замовлення».
  3. Вводить адресу доставки.
  4. Обирає спосіб оплати.
  5. Підтверджує замовлення.
  6. Система створює замовлення і відправляє підтвердження.
  • Альтернативний сценарій:

3a. Якщо адреса не введена — система показує помилку.

4a. Якщо не обрано спосіб оплати — система не дозволяє перейти далі.

Тест-кейси:

ID

Кроки

Очікуваний результат

TC01

Успішне оформлення всіх кроків

Замовлення створено, підтвердження на пошті

TC02

Пропущено адресу

Повідомлення про обов’язковість поля

TC03

Не обрано спосіб оплати

Користувач не може завершити замовлення

Рекомендації щодо створення тест-кейсів на основі Use Cases

  • Вивчити специфікації або UML-діаграми (особливо Use Case Diagrams).
  • Ідентифікувати всі основні та альтернативні сценарії.
  • Для кожного варіанта — створити окремий тест-кейс.
  • Забезпечити охоплення як позитивних, так і негативних сценаріїв.
  • Пріоритетність тестів може визначатись на основі важливості сценаріїв для бізнесу.

Use Case Testing дозволяє охопити ключову функціональність з урахуванням реального досвіду користувача. Це підвищує якість системи в очах бізнесу й клієнтів. Методика добре поєднується з іншими техніками, особливо у складних інтеграційних або бізнес-орієнтованих проєктах.

Сценарне тестування (Scenario Testing)

Сценарне тестування — це техніка тест-дизайну, в якій тестування ґрунтується на реалістичних сценаріях використання системи, що включають послідовність дій користувача в контексті певної задачі або

бізнес-процесу. Сценарії будуються так, щоб перевірити логіку роботи функціоналу в цілісних, завершених ситуаціях, а не ізольованих умовах.

Техніка застосовується, коли:

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

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

Основні характеристики

  • Фокус на користувачі — сценарії створюються з точки зору кінцевого користувача.
  • Базуються на вимогах, кейсах використання або бізнес-процесах.
  • Містять декілька кроків — перевіряється не окрема дія, а послідовність.
  • Орієнтація на позитивні сценарії (happy path), але можуть включати й відхилення.

Побудова сценаріїв

Сценарії можуть будуватись на основі:

  • user stories — короткий опис функціональності з точки зору користувача, зазвичай у форматі: «як користувач, я хочу... щоб...»;
  • use cases — структуровані описи взаємодій між користувачем і системою для досягнення певної цілі;
  • бізнес-правил та процесів;
  • діаграм активності або послідовності;
  • знань домену або попередніх інцидентів.

Добре побудований сценарій має бути:

  • реалістичним — відповідає дійсному способу використання;
  • повним — має чіткий початок і завершення;
  • перевірним — містить конкретні очікування або критерії успіху.

Приклад

Контекст: вебзастосунок для бронювання квитків на поїзд.

Задача: Створити сценарій для перевірки повного процесу бронювання квитка, включно з вибором маршруту, введенням даних пасажира, оплатою та підтвердженням.

Сценарій: успішне бронювання квитка з оплатою банківською карткою

Крок

Дія користувача

Очікувана поведінка системи

1

Користувач заходить на головну сторінку

Відображається форма пошуку маршруту

2

Вибирає місто відправлення та призначення, дату

Активується кнопка «Пошук»

3

Натискає «Пошук»

Відображається список доступних рейсів

4

Вибирає потрібний рейс і натискає «Продовжити»

Відображається форма введення даних пасажира

5

Вводить ім’я, прізвище, e-mail

Поля заповнюються коректно, кнопка «Оплатити» активується

6

Обирає «Оплата карткою» і вводить дані картки

Дані передаються в платіжний шлюз

7

Підтверджує оплату

Система показує сторінку з підтвердженням бронювання

8

Отримує e-mail з квитком

Користувач отримує лист із деталями подорожі та pdf-квитком

Побудова тест-кейсів на основі сценарію

ID

Опис тест-кейсу

Очікуваний результат

TC01

Повне бронювання квитка з коректними даними

Успішне бронювання, e-mail з квитком отримано

TC02

Введення некоректної e-mail адреси

Відображається повідомлення про помилку, кнопка «Оплатити» не активна

TC03

Відмова в оплаті (відхилення банком)

Повідомлення про помилку оплати, можливість повторити дію

TC04

Переривання сесії до підтвердження бронювання

Бронювання не створене, користувач повертається до форми пошуку

TC05

Вибір рейсу, але незаповнені дані пасажира

Кнопка «Оплатити» не активна, підсвічуються обов’язкові поля

  • Сценарне тестування дозволяє перевірити бізнес-логіку в умовах, максимально наближених до реального використання.
  • Підходить для приймального тестування (acceptance testing), тестування на рівні системи (system testing), а також UAT.
  • Створені сценарії легко обговорювати із зацікавленими сторонами та бізнесом.
  • Вимагає більше зусиль для підтримки при зміні логіки або інтерфейсу.

Тестування на основі контрольних списків (Checklist-based Testing)

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

Ця техніка застосовується у випадках, коли:

  • необхідно забезпечити перевірку стандартного набору функцій, поведінки чи вимог;
  • є потреба у швидкому проходженні по ключових сценаріях без формального документування тест-кейсів;
  • тестування виконується вручну й важливо уникнути пропусків під час виконання;
  • потрібно забезпечити якісне smoke testing, acceptance testing, regression testing або exploratory testing.

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

Основні характеристики

  • Неформальний підхід — не вимагає створення повноцінних тест-кейсів.
  • Стандартизований — дозволяє узгодити перелік критичних перевірок.
  • Гнучкий — легко адаптується або розширюється.
  • Повторюваний — може багаторазово використовуватись у різних проєктах.

Джерела для побудови контрольних списків

  • специфікації або вимоги;
  • стандарти якості (наприклад, UX-гайди, security-стандарти);
  • результати попереднього тестування (дефекти, інциденти);
  • набутий досвід і знання команди;
  • стандартні аспекти тестування (UI, логування, валідація, повідомлення про помилки тощо).

Приклад

Контекст: система керування замовленнями в інтернет-магазині.

Задача: перевірити коректність роботи основних функцій оформлення замовлення з використанням контрольного списку.

Приклад контрольного списку

Елемент перевірки

Примітка

1

Можливість додати товар у кошик

Для різних типів товарів

2

Відображення кількості товарів у кошику

Включно з оновленням у реальному часі

3

Можливість видалити товар із кошика

Перевірка очищення кошика

4

Перехід до оформлення замовлення

Із кошика або прямо зі сторінки товару

5

Валідація обов’язкових полів під час оформлення

Ім’я, адреса, спосіб доставки

6

Можливість вибору способу оплати

Картка, післяплата, PayPal

7

Повідомлення про успішне оформлення замовлення

Відображення ID замовлення, лист на email

8

Неможливість оформити замовлення з порожнім кошиком

Очікуване повідомлення про помилку

Побудова тест-кейсів на основі контрольного списку

ID

Опис тест-кейсу

Очікуваний результат

TC01

Додати кілька товарів у кошик

Всі обрані товари відображаються з правильною кількістю

TC02

Оформити замовлення без заповнення адреси доставки

Виводиться повідомлення про помилку, оформлення неможливе

TC03

Вибрати PayPal як спосіб оплати та завершити замовлення

Замовлення підтверджене, платіж через PayPal успішний

TC04

Очистити кошик і спробувати оформити замовлення

Виводиться помилка «кошик порожній»

  • Тестування на основі контрольних списків — ефективний спосіб забезпечити базовий рівень якості в умовах обмеженого часу.
  • Не забезпечує глибокого покриття, але дозволяє систематизувати ручну перевірку.
  • Може використовуватись як частина exploratory testing або бути основою для майбутньої автоматизації.
  • Рекомендується оновлювати контрольні списки після кожного тестового циклу з урахуванням нових виявлених ризиків.

Отже, ми розглянули базові та найпоширеніші техніки тест-дизайну з категорії чорної скриньки, що дозволяють будувати ефективні та обґрунтовані тестові сценарії, не заглиблюючись у код. Це корисно як для ручного, так і для автоматизованого тестування. А в другій частині поговоримо про підходи білого ящика, зокрема про покриття операторів, гілок, умов, а також інші методи, що ґрунтуються на аналізі структури коду.

👍ПодобаєтьсяСподобалось23
До обраногоВ обраному14
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі