Техніки тест дизайну: навіщо їх знати QA-команді
Коли на проєкті 200+ вимог, а реліз через тиждень, команда не може перевірити все. Техніки тест дизайну допомагають обрати мінімум тестів, який дасть максимум покриття. Це конкретні правила, за якими QA-інженер перетворює вимоги на кейси: що перевіряти, скільки разів, у якій послідовності і з якими даними. Без них тестування перетворюється або на хаотичний клік, або на безкінечну регресію, яка все одно щось пропускає.
На практиці в українських аутсорс- та продуктових командах найчастіше використовують 7-9 базових технік. Вони входять у syllabus ISTQB і застосовуються і до мобільних застосунків, і до банківського ПЗ, і до ERP. Різниця лише в тому, як саме інженер адаптує техніку під свій домен: форми, API, чорну скриньку чи state-машини.
Нижче розібрано кожну техніку тест дизайну, яка реально працює в продакшені, а не лише в підручниках. Для кожної є приклад, типовий набір тестових даних і часта помилка, через яку техніка дає хибне відчуття покриття.
Класифікація технік тест дизайну за ISTQB
За класифікацією ISTQB Foundation Level усі техніки поділяються на три великі групи за типом знань про систему, які використовує інженер.
Статичні техніки
Застосовуються до коду, вимог і специфікацій без запуску самого ПЗ. Це рев’ю, walkthrough, інспекції, статичний аналіз коду. У цьому матеріалі фокус саме на динамічних техніках, бо статичні зазвичай не входять у поняття test design у вузькому сенсі.
Техніки на основі специфікацій (чорна скринька)
Тести створюються з вимог, без знань внутрішньої структури. Сюди належать: розбиття на класи еквівалентності, аналіз граничних значень, таблиця рішень, переходи станів, попарне тестування, варіантне тестування, сценарії використання (use case testing), а також техніка дослідницького тестування. Це основа для функціональних перевірок, особливо коли код ще не написаний або змінюється щодня.
Техніки на основі структури (біла скринька)
Тести формуються на основі внутрішньої будови: операторів, гілок, шляхів, циклів. Це покриття операторів, гілок, умов, MC/DC. Застосовується там, де критична безпека: авіа, медицина, банківські ядра, де вимоги регуляторів вимагають конкретного рівня покриття коду.
Досвідчені QA-ліди комбінують обидві групи. Чорна скриняка дає широту, біла скринька – глибину. Наприклад, для поля віку: чорна скриняка перевіряє, що 0-150 приймається, а від’ємні значення ні. Біла скринька перевіряє, що гілка коду з валідацією дійсно виконується при граничному значенні, а не «загортається» через оптимізацію компілятора.
Техніки на основі досвіду
До них відносять error guessing і exploratory testing. Вони не гарантують систематичного покриття, але добре ловлять неочевидні баги. На практиці їх використовують як доповнення до формальних технік, а не як заміну.
Основні техніки тест дизайну чорної скриньки
Розберемо кожну техніку з прикладом, який зустрічається в реальних проєктах: форма реєстрації з полями «ім’я», «вік», «підписка на новини».
Розбиття на класи еквівалентності (Equivalence Partitioning)
Суть: вхідні дані поділяються на групи, в межах яких система має поводитися однаково. З кожної групи береться одне значення. Це різко зменшує кількість тестів без втрати покриття. Для поля «вік» (валідне 18-90): один невалідний тест з віком 5, один валідний з 25, один невалідний з 120. Три тести замість сотні.
Часта помилка – ігнорувати «сірі» класи: наприклад, поле приймає 17, але блокує реєстрацію. Це окремий клас поведінки, а не просто невалідне значення. В документації ISTQB такі випадки виносять в окремі розділи і тестують як окремий сценарій.
Аналіз граничних значень (Boundary Value Analysis)
Перевіряються самі межі і значення поряд з ними: 17, 18, 19 для нижньої межі, 89, 90, 91 для верхньої. Більшість дефектів ховається саме на межах через помилки з > vs >=, off-by-one, неправильне округлення. Це одна з найдешевших і найефективніших технік, яка майже завжди дає результат.
Практичне доповнення: додатково перевіряйте значення на 1 і 2 кроки всередину межі. Приклад: якщо вік 90 максимальний, перевірте 90, 89 і 88. Іноді значення «працює» на 89, але не на 90 через неправильне округлення валідатора.
Таблиця рішень (Decision Table)
Підходить для бізнес-логіки з комбінаціями умов. Наприклад, форма підписки: клієнт з промокодом + новий користувач + сума > 1000 = знижка 15%. Таблиця рішень робить усі комбінації видимими і прибирає пропущені сценарії. Найчастіше її будують у Confluence, а потім переносять у TestRail або Zephyr.
Тестування переходів станів (State Transition)
Використовується там, де поведінка залежить від попереднього стану: замовлення (створено оплачено відправлено доставлено повернуто). Діаграма станів дозволяє побачити невалідні переходи (наприклад, «доставлено оплачено») і перевірити, що система їх блокує або обробляє коректно.
Попарне тестування (Pairwise / All-Pairs)
Скорочує комбінаторний вибух. Якщо є 3 поля по 4 значення, повний набір – 64 комбінації. All-Pairs дає 9-12 тестів, які покривають усі можливі пари значень. Інструменти: PICT від Microsoft, ACTS, Hexawise. Найчастіше використовується для конфігурацій: браузер × ОС × версія ПЗ, де повна матриця нереалістична.
Мінус: попарне тестування не ловить баги, які залежать від трьох параметрів одночасно. Тому для критичних сценаріїв (безпека, фінанси) його доповнюють ручним добором «небезпечних» трійок.
Сценарії використання (Use Case Testing)
Тести будуються на основі реальних сценаріїв користувача, а не абстрактних вимог. Наприклад, «користувач додає товар у кошик, застосовує промокод, оплачує карткою, отримує email». Це допомагає знаходити інтеграційні дефекти, які не видно з рівня окремих полів.
Варіантне тестування (Variation Testing / Domain Testing)
Це перевірка поведінки системи на граничних, типових і «дивних» значеннях у межах одного домену. Наприклад, для дати: 29 лютого 2024 року (валідно), 31 квітня (невалідно), 31 грудня 23:59:59 (граничне), 01 січня 00:00:00 (початок нового періоду). Особливо актуально для систем з податковими чи фінансовими періодами.
| Техніка | Тип знань | Коли дає максимум | Типовий ризик при помилковому застосуванні |
|---|---|---|---|
| Класи еквівалентності | Чорна скринька | Валідація полів, форм, API-параметрів | Пропуск «сірих» класів, де поведінка частково валідна |
| Граничні значення | Чорна скринька | Числові поля, ліміти, дати, версії | Перевірка тільки межі, без 1 кроку всередину |
| Таблиця рішень | Чорна скринька | Бізнес-правила зі складними умовами | Дублювання рядків без оптимізації таблиці |
| Переходи станів | Чорна скринька | Замовлення, документи, workflow-системи | Ігнорування невалідних переходів |
| Попарне тестування | Чорна скринька | Конфігурації, форми з багатьма полями | Пропуск багів, що залежать від трьох параметрів |
| Use case testing | Чорна скринька | Інтеграційні сценарії, e-commerce, fintech | Спрощення сценарію до одного кроку замість повного шляху |
| Варіантне тестування | Чорна скриняка | Дати, числові домени, формати | Відсутність перевірки переходу між періодами |
Техніки на основі структури коду
Ці техніки вимагають доступу до коду і використовуються там, де критична повнота покриття: авіа, медичні системи, банківські ядра, залізничні системи. Рівень покриття тут часто регулюється стандартами (наприклад, DO-178C для авіації вимагає MC/DC для рівня A).
Покриття операторів і гілок
Найпростіша метрика: який відсоток рядків коду виконано під час тестів. Інструменти: JaCoCo для Java, coverage.py для Python, Istanbul для JS. Для проєктів без жорстких регуляторних вимог 70-80% покриття операторів вважається достатнім. Покриття гілок (branch coverage) – сильніший критерій: перевіряється, що виконано і true-, і false-гілка кожної умови.
Покриття умов і рішень
Тут перевіряється кожна булева умова окремо. Наприклад, для виразу if (a > 0 && b < 10) треба перевірити всі чотири комбінації a і b. Це дорожче, але ловить логічні помилки, які branch coverage пропускає.
MC/DC (Modified Condition/Decision Coverage)
Найсуворіший критерій: кожна умова повинна вплинути на результат рішення хоча б один раз. Використовується в авіації, медичній техніці, залізничних системах. На практиці потребує спеціалізованих інструментів і значно більше тестів, ніж просте покриття гілок. Для більшості комерційного ПЗ він надмірний, але для критичних систем – обов’язковий.
Техніки на основі досвіду
Ці техніки не дають формального покриття, але добре працюють як доповнення. Вони не замінюють формальні методи, а ловлять те, що формальні методи пропускають.
- Error guessing – інженер передбачає, де розробник міг припуститися помилки: валідація, граничні значення, обробка помилок API, ділення на нуль, race conditions.
- Exploratory testing – 60-90 хвилин цілеспрямованого дослідження продукту з нотатками, без заздалегідь написаних кейсів. Працює як «другий погляд» на функціонал, який щойно пройшов формальні тести.
- Checklist-based testing – готовий чек-ліст типових перевірок для конкретного типу додатків. Наприклад, для мобільного застосунку: робота офлайн, переривання дзвінком, зміна мови, темна тема, push-сповіщення.
Як поєднувати техніки тест дизайну на практиці
На реальному проєкті одна техніка майже ніколи не дає повного результату. Оптимальна стратегія залежить від типу продукту, етапу розробки і регуляторних вимог.
Форми та валідація
Спочатку класи еквівалентності + граничні значення. Додатково – варіантне тестування для специфічних полів (дата, телефон, IBAN). Error guessing як фінальний шар для типових «дивних» кейсів: SQL-ін’єкції, XSS, Unicode-символи, порожні значення з пробілами.
API та інтеграції
Таблиця рішень для бізнес-логіки, попарне тестування для комбінацій параметрів, перевірка станів для довготривалих процесів. Плюс обов’язково error guessing на нестандартні HTTP-коди, тайм-аути, повторні запити з тим самим ідемпотентним ключем.
Складні workflow
Переходи станів – основна техніка, use case – для довгих сценаріїв користувача, таблиця рішень – для бізнес-правил усередині кожного стану. Наприклад, для замовлення: таблиця рішень для розрахунку знижки, переходи станів для життєвого циклу, use case для повного сценарію покупки.
Критичні системи
Додаються біла скринька з MC/DC і формальні методи верифікації. Тут техніки тест дизайну перетинаються з формальними методами доведення коректності, і їх використання регулюється зовнішніми стандартами (ISO 26262 для авто, IEC 62304 для медичних пристроїв, DO-178C для авіації).
Як обрати техніку для конкретного завдання
Українські QA-команди часто починають з «написати 100 тестів», замість того щоб спершу визначити, яка техніка тут дасть максимум результату. Короткий алгоритм:
- Визначте, що саме перевіряєте: валідацію полів, бізнес-логіку, стани, конфігурації, сценарії користувача, код.
- За типом задачі оберіть базову техніку: валідація еквівалентність + границі, логіка таблиця рішень, стани переходи станів, сценарії use case.
- Додайте другу техніку як перехресну перевірку: наприклад, граничні значення + use case.
- Закрийте сірі зони через error guessing і exploratory testing.
- Зафіксуйте, яке покриття ви отримали, і чи є прогалини, які варто закрити на наступній ітерації.
Наприклад, для поля «знижка» (0-50%): класи еквівалентності (0-50, від’ємні, > 50) + граничні значення (-1, 0, 1, 49, 50, 51) + use case (як знижка впливає на фінальну суму і доставку). Без такої комбінації можна пропустити, що 0% знижки не «показується» в чеку, а 50% ламає бонусну систему.
Поширені помилки при застосуванні технік
Навіть досвідчені інженери припускаються одних і тих самих помилок. Ось ті, що найчастіше зустрічаються на рев’ю тестової документації.
- Підміна техніки кліками: тести «просто клацають», а формальної логіки під ними нема. Це особливо помітно на проєктах, де тести пишуть розробники паралельно з кодом і не переглядають їх окремо.
- Ігнорування сірих зон: наприклад, 17 років – «невалідно для реєстрації», але «валідно для API запиту». Це два різні класи еквівалентності, а не один.
- Повне покриття операторів без перевірки гілок: 90% рядків коду вкрито, але жодного false-випадку для критичних умов. Метрика виглядає добре, баги лишаються.
- Попарне тестування без розуміння ризиків: для системи, де конфігурація 1+2+3 разом створює дефект, all-pairs його не знайде.
- Відсутність документування обраної техніки: через півроку ніхто не пам’ятає, чому саме цей набір тестів такий. При ротації QA-команди це перетворюється на втрату контексту.
Як техніки тест дизайну вписуються у процес
Техніка – це лише один крок у ланцюжку: аналіз вимог дизайн тестів написання кейсів виконання репортування метрики. Без дизайну два інженери з однаковими вимогами створять різні набори тестів, а з технікою – порівнянні. Це особливо цінно в розподілених командах, де QA сидить у Львові, а розробник – у Києві.
На практиці техніки найчастіше застосовуються саме на етапі дизайну, а в TestRail / Zephyr потрапляють уже готові кейси з прив’язкою до вимог. Це дає змогу прорахувати покриття вимог тестами і виявити «голі» вимоги, до яких немає жодного тесту.
Інструменти для автоматизації технік
Частину технік можна автоматизувати або принаймні формалізувати за допомогою спеціалізованих інструментів. Це не замінює інженера, але прискорює рутину.
- PICT, ACTS, Hexawise – генерація попарних наборів для all-pairs тестування.
- JaCoCo, Cobertura, Istanbul, coverage.py – аналіз покриття коду для білої скриньки.
- TestRail, Zephyr, qTest, Qase – структурування кейсів із прив’язкою до вимог і технік.
- Allure, ReportPortal – аналіз результатів і трендів за типами дефектів.
Важливо: інструменти лише допомагають застосувати техніку, але не обирають її. Помилка «інженер довірився PICT і отримав неповне покриття» – типова, коли не враховані трійки або сценарії, специфічні для домену.
Як виміряти ефективність техніки
Метрика проста: відсоток знайдених дефектів до загальної кількості дефектів у релізі. Якщо техніка чорної скриньки дає 70% знайдених багів, а білої – 90%, але біла потребує в 5 разів більше часу, то для комерційного ПЗ оптимальною є комбінація: чорна скринька як основа, біла – для критичних модулів.
На довгих проєктах (підтримка ПЗ 3+ роки) варто вести реєстр: яка техніка дала який тип дефекту. Це допомагає річно переглядати стратегію тестування і відмовлятися від технік із низьким виходом.
Міжнародні стандарти та практики
Техніки тест дизайну формалізовані в ISTQB Syllabus, ISO/IEC/IEEE 29119 і регуляторних стандартах для критичних галузей. Для комерційного ПЗ дотримання ISTQB Foundation Level уже є стандартом de facto в ЄС і Україні. Для критичних систем – додатково DO-178C, ISO 26262, IEC 62304.
Згідно з матеріалами Wikipedia про test design, більшість технік, які зараз входять у syllabus ISTQB, були формалізовані в 1970-1990-х роках на основі практик IBM та Bell Labs. Відтоді базовий набір залишається стабільним, але інструменти автоматизації і підходи до інтеграції з CI/CD значно розширилися.
Дослідження, опубліковане в огляді ScienceDirect про software testing, показує, що комбінація технік чорної та білої скриньки дає в середньому на 35% більше знайдених дефектів на годину роботи інженера, ніж використання лише однієї групи. Це узгоджується з практикою більшості зрілих QA-команд, які поєднують функціональні та структурні підходи.
В українському IT-секторі техніки тест дизайну входять у вимоги до сертифікації QA-інженерів у більшості аутсорсингових компаній. Сертифікація ISTQB Foundation Level, яка охоплює всі базові техніки, залишається обов’язковою для позицій Manual QA і Junior Automation у Львові, Києві, Одесі та Дніпрі. Це одна з причин, чому розуміння технік тест дизайну вважається обов’язковим для входу в професію.
Часті запитання (FAQ)
Скільки технік тест дизайну реально потрібно знати Junior QA?
Для старту достатньо 4-5 базових: класи еквівалентності, граничні значення, таблиця рішень, переходи станів і use case testing. Цього вистачить для 80% функціональних перевірок на реальних проєктах. Решту технік варто вивчати за потребою, коли проєкт вимагає попарного тестування або покриття коду.
Чи можна обмежитися лише однією технікою, наприклад класами еквівалентності?
Технічно так, але тоді ви отримаєте «діряве» покриття. Класи еквівалентності добре працюють для валідації полів, але майже не ловлять баги в бізнес-логіці чи workflow. На практиці завжди потрібна комбінація технік: для валідації – еквівалентність + границі, для логіки – таблиця рішень, для процесів – переходи станів.
Як поєднувати техніки чорної та білої скриньки?
Чорна скринька дає широту, біла – глибину. Спочатку пишете функціональні кейси, потім дивитесь, які гілки коду ними не покриваються, і додаєте структурні тести. Наприклад, для API спочатку use case «створити замовлення», потім branch coverage на 100% для модуля валідації.
Чи заміняє автоматизація техніки тест дизайну?
Ні. Автоматизація прискорює виконання тестів, але не замінює етап дизайну. Без грамотного дизайну автоматизовані тести просто швидко виконують нерелевантні кейси. Спочатку дизайн, потім автоматизація найважливіших сценаріїв.
Які техніки найчастіше ігнорують QA-початківці?
Найчастіше пропускають таблицю рішень і переходи станів. Без таблиці рішень легко пропустити комбінації умов, особливо коли бізнес-логіка описана словами. Без переходів станів пропускають невалідні стани, наприклад спробу скасувати доставлене замовлення.
Чи є сенс вивчати техніки, якщо вже працюю з BDD і автоматизацією?
Так, BDD – це інший рівень. Сценарії BDD часто пишуть на основі тих самих технік тест дизайну, особливо use case testing і таблиці рішень. Без розуміння технік сценарії BDD виходять «водянистими»: одна й та сама дія перевіряється 20 разів у різних формулюваннях, а рідкісні сценарії лишаються без покриття.
Як перейти від ручного дизайну до автоматизованого?
Почніть з автоматизації найбільш повторюваних кейсів: граничні значення, валідація полів, smoke-сценарії. Використовуйте PICT для генерації попарних наборів і coverage-інструменти для аналізу білої скриньки. Не автоматизуйте все підряд: exploratory testing і error guessing лишаються ручними навіть у найзріліших командах.
Чи є техніки, специфічні для мобільних або веб-додатків?
Базові техніки однакові, але додаються специфічні перевірки. Для мобільних: робота офлайн, переривання, push-сповіщення, gesture-тестування. Для веб: крос-браузерність, адаптивність, доступність (a11y). Попарне тестування особливо цінне саме для конфігурацій браузер × ОС × версія.
Як пояснити техніки тест дизайну замовнику або продакт-менеджеру?
Через бізнес-цінність: «ми не пишемо 200 тестів, ми пишемо 30, які покривають усі типові сценарії і дають впевненість, що реліз не зламає ключовий функціонал». Покажіть приклад класу еквівалентності з вашого проєкту: 3 тести замість 50, той самий результат. Це працює краще, ніж теоретичне пояснення технік.
Залишити відповідь