Техніки тест-дизайну: як тестувати розумніше, а не складніше

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

Всім привіт! Я — Аня, Middle QA у Bookboost, і сьогодні ми поговоримо про техніки тест-дизайну.

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

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

Тест-дизайн і його види

Тест-дизайн (Test Design) — це етап процесу тестування ПЗ, на якому проєктуються та створюються тест-кейси відповідно до визначених раніше критеріїв якості й завдань тестування.

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

Техніки тест-дизайну поділяються на:

• Black-box testing (або рідше — Behavioral testing) — це метод тестування програмного забезпечення, де тестувальник не має доступу до вихідного коду системи.
• White-box testing (Structural, Structure-based) — зосереджується на внутрішньому функціонуванні системи.
• Experience-based testing — тестування на основі досвіду, не є типовим методом. Це динамічний підхід, який спирається на інтуїцію, навички та минулий досвід тестувальника.

Сьогодні ближче ознайомимося з техніками чорної скриньки та розглянемо їх на прикладах. Я виділила шість важливих технік тест-дизайну методом чорної скриньки:

Еквівалентне розподілення (Equivalence Partitioning)

Equivalence Partitioning — техніка тест-дизайну, яку використовують для розділення вхідних даних на еквівалентні класи щодо їхніх дій на систему.

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

Приклад:

Юзер має вказати своє медичне ID в полі введення. Допустимі лише валідні значення:

• тільки цифри;
• не більш як сім символів.

Погрупуємо дані на класи еквівалентності:

На цьому кейсі я виділила чотири еквівалентні класи:

1. Перший клас (from 0 till 9999999) — валідний: будь-яка комбінація цифр зі значень, менших за сім. Тобто юзер може ввести мінімальну кількість цифр (1, 2, 3, 4,..) або максимальну (будь-яке семизначне число — 6789023).
2. Другий клас (> = 10000000) — невалідний: лише числа, які містять більш як сім значень.
3. Третій клас (letters, symbols, spaces) — невалідний: це будь-які символи, пробіли, букви або цифри + символи / букви.
4. Четвертий клас (empty field) — невалідний: пусте поле. Необхідно перевірити, чи дозволить система користувачу зберегти такі дані. Це стосується випадку, якщо поле required. Якщо поле не є обов’язковим, цей кейс буде валідним і треба протестувати, чи дозволить система користувачу не вводити значення для цього поля.

Після розділення даних на класи я прописую тест-кейси.

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

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

Boundary Value Analysis (BVA) — техніка тест-дизайну, у якій тест-кейси розроблені на основі граничних значень.

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

Ідея: розділити умови тестування на класи та перевірити межі між цими класами. Тест-кейси мають бути написані для кожного граничного значення.

Приклад:

Ціна доставки залежить від ваги товару. Для товару до 25 кілограмів включно вартість доставки становитиме $14,5. Якщо товар завважки від 26 до 55 кг, ціна буде $28. А якщо вага товару понад 55 кг, то ціна доставки зросте до $50.

Я виділила три класи еквівалентності, які стосуються цього випадку.

1. Перший клас — 0–25: для цього класу під час вибору аналізу граничних значень мінімальним значенням буде 0 кг (або мінімальне значення, яке є в системі; часто для товарів з малою вагою ставлять 0 або 1 кг). Максимальне значення для цього класу — 25 кг.
2. Другий клас — 26–55: мінімальне значення — 26 кг, максимальне — 55 кг.
3. Третій клас — 56 — ∞: у цьому випадку в нас є лише мінімальне значення 56 кг.

Проте максимальне значення можна отримати, якщо така статистика є в системі (максимальна кількість кілограмів за одну клієнтську покупку від реального користувача).
Або можна порахувати максимальну суму ваги всіх товарів, які здатен купити користувач за один раз. Наприклад, установлено ліміт: 10 товарів за одну покупку. Максимальна вага товару — 15 кг. Відповідно, 15*10 = 150 кг. Тобто наш клієнт максимально може здійснити одну покупку товару вагою 150 кг.

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

Таблиця ухвалення рішень (Decision table)

Decision table — таблиця причинно-наслідкових зв’язків, які можна використовувати для розробки тест-кейсів.

Ідея: розділити умови тестування на обмеження, які можуть мати позитивне або негативне значення, і правила, які ідентифікують результат на основі значень умов.

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

Приклад:

Для відправлення форми юзеру необхідно завантажити файл, що можна зробити за таких умов:

• документ лише формату .pdf;
• розмір — не більш як 10 MB;
• лише один файл за раз.

Отже, складаємо таблицю ухвалення рішень.

У контексті decision table нам потрібно визначити всі можливі випадки. Якщо в нас три умови, то кількість випадків рахуємо як 2^n, де n — це кількість випадків, тобто 2^3 = 8:

Згідно з таблицею, в нас буде вісім тест-кейсів:

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

State Transition testing — техніка розробки тест-кейсів, у якій тест-кейси розроблені для виконання дійсних і недійсних переходів станів. Перехід стану — перехід між двома станами компоненти або системи.

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

Приклад:

Ордери в системі мають декілька статусів. Залежно від випадку, ордери можуть змінювати свій статус.

Ордер має статус New, якщо він тільки створений. Далі ордер стає Paid, якщо користувач оплатив за нього протягом трьох днів. В іншому випадку ордер змінює статус на Unpaid. Ордер у статусі Unpaid може перейти в Cancelled, якщо користувач відмовився від нього, а якщо юзер оплатив — стати Paid.

Малюємо діаграму переходу станів.

Ця діаграма показує, що під час зміни стану можна виділити три тестові випадки:

1-й тест-кейс:

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

2-й тест-кейс:

Перевірити, чи ордер отримає статус Paid, якщо юзер оплатив після трьох днів:

3-й тест-кейс:

Перевірити, чи ордер отримає статус Cancelled, якщо юзер попросив скасувати його після неоплати:

Тестування за допомогою сценаріїв використання (Use Case testing)

Use Case testing — це техніка, що допомагає нам ідентифікувати тестові випадки, які перевіряють усю систему на основі транзакцій від початку до кінця.

Use Case є записом ітерацій між Actor (дійова особа) та System (система). Основна термінологія щодо use cases:

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

Ідея:

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

Приклад:

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

Попарне тестування (Pairwise testing)

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

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

Приклад:

У магазині є декілька видів доставок для декількох країн. Візьмемо зі списку дві доставки та дві країни для кращого розуміння. Отож нам потрібно буде протестувати такі комбінації:

Можна побудувати кількість тест-кейсів для перевірки згідно з першою табличкою. У цьому випадку в нас є дві країни та два методи доставки, тому тест-кейсів буде 2*2 = 4. Оскільки тестів небагато, ми можемо просто попарно перетестувати всі значення.

Розгляньмо складніший випадок: додамо спосіб оплати за доставку.

Таким чином кількість тест-кейсів збільшиться і становитиме 4*2 = 8 тестових випадків.
Тут можна застосувати попарне тестування, відповідно, кількість тестових випадків скоротиться до чотирьох. Щоб побудувати таку матрицю, необхідно переконатися, що будь-які два стовпці містять усі можливі комбінації лише один раз. (В моєму прикладі є дві можливі комбінації країн та методів доставки.)

Для більш оптимального рішення та заощадження часу можна використовувати спеціальні тулзи для Pairwise testing. Наприклад, сервіс Pairwise Online Tool або утиліту Allpairs.

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

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

Висновок

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

Black-box testing оцінює функціональність програмного забезпечення з погляду кінцевого користувача і має багато переваг, як-от доступність для не-розробників і можливість раннього тестування. Утім, у методу є і мінуси, зокрема обмежена видимість коду та потенційні витрати часу на ручне тестування.