Manual QA

Техніки тест-дизайну

як вибрати, що тестувати

Що таке класи еквівалентності?

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

Приклад: сума переказу 1–10 000 грн. Класи: менше 1 (невалідний), 1–10 000 (валідний), понад 10 000 (невалідний), а ще нечислові значення й порожнє поле.

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

Що таке аналіз граничних значень?

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

Для 1–10 000: 0, 1, 2 і 9 999, 10 000, 10 001. Для грошей важливі ще дробові межі: 0.99, 1.00, 1.01 і 10 000.00 / 10 000.01.

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

Що таке таблиця рішень і коли її використовувати?

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

Умова / правило	1	2	3	4
Достатньо коштів	Так	Так	Ні	Ні
Ліміт не перевищено	Так	Ні	Так	Ні
Результат	Переказ	Відмова: ліміт	Відмова: кошти	Відмова: кошти

Таблиця одразу показує пропущені комбінації і питання до вимог: яку помилку показати, коли не виконано обидві умови?

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

Що таке тестування переходів станів?

Для об'єктів, які проходять через стани: замовлення, платіж, акаунт. Будуємо діаграму станів і переходів і тестуємо валідні переходи, а також невалідні — що система не дозволяє їх.

Платіж:
  Created → Pending → Authorized → Captured → Settled
                    ↘ Declined
  Captured → Refunded

Невалідні переходи для тесту:
  Declined → Captured    (не можна списати відхилений)
  Refunded → Refunded    (подвійне повернення)
  Created  → Settled     (пропуск кроків)

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

Що таке pairwise-тестування?

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

Приклад: 3 браузери × 3 ОС × 3 мови × 2 типи акаунта = 54 комбінації; pairwise скорочує до ~9–12. Генерують інструментами на кшталт PICT або онлайн-генераторів.

На співбесіді: Pairwise допомагає, коли параметрів забагато для перебору всіх комбінацій. Більшість багів виникає від взаємодії двох параметрів, тому я покриваю всі пари значень. Наприклад, п'ятдесят чотири комбінації браузерів, ОС і мов скорочуються приблизно до десяти, і я генерую їх інструментом.

Що таке error guessing і чеклісти на основі досвіду?

Тестування на основі досвіду: де зазвичай ламається? Порожні поля, пробіли на початку і в кінці, дуже довгі рядки, спецсимволи й емодзі, подвійний клік, кнопка «Назад», оновлення сторінки посеред процесу, втрата мережі, кілька вкладок, відкритих одночасно.

Це доповнення до формальних технік, а не заміна.

На співбесіді: Error guessing — це коли я з досвіду знаю типові місця поломок: порожні поля, спецсимволи, подвійний клік, оновлення сторінки посеред процесу, обрив мережі. Я використовую його разом з формальними техніками, а не замість них.

Класи еквівалентності та граничні значення: вік 18–65

Класи еквівалентності ділять вхідні дані на групи, де система поводиться однаково, тож достатньо одного значення з кожного класу. Для поля «вік 18–65» маємо валідний клас 18–65 і два невалідні: менше 18 та більше 65. Представники: 30, 10 і 80.

Граничні значення перевіряють межі, бо там найчастіше помиляються розробники. Для двоточкового підходу беру 17, 18, 65, 66; для триточкового — 17, 18, 19, 64, 65, 66. Очікувано 18 і 65 приймаються, 17 і 66 — ні.

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

Decision table і state transition

Decision table використовується, коли результат залежить від комбінації кількох умов. Наприклад, знижка: чи є користувач VIP і чи сума замовлення більше 1000 гривень. Будуємо таблицю з усіма комбінаціями умов і очікуваними діями — так видно пропущені або суперечливі правила.

Для n бінарних умов буде 2 в степені n комбінацій, тому таблицю часто скорочують, об'єднуючи правила, де якась умова не впливає на результат. Ця техніка корисна для бізнес-правил, тарифів, прав доступу.

State transition застосовується, коли система має стани й переходи між ними. Приклад — замовлення: New → Paid → Shipped → Delivered, з можливим переходом у Cancelled. Тестуємо всі валідні переходи і перевіряємо, що невалідні заборонені, наприклад скасувати вже доставлене замовлення неможливо.