Що не так із застосуванням техніки «Аналіз класів еквівалентності»

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

Привіт, шановні колеги. Мене звати Володимир Поздняков. Я QA-інженер з майже 6-річним стажем роботи в аутсорсі. Починав з ручного тестування, виріс в QA Lead, а зараз більшу частину часу займаюсь автоматизованим тестуванням.

Отже, якщо з формальною, не дуже цікавою частиною покінчено, перейдімо до теми розмови, а саме: «Техніки тест-дизайну».

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

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

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

Приклади тест-дизайну, в яких щось пішло не так

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

Легковайті Тестущенко: Пфф. Легко! Це саме зрозуміле і легке, що може бути. Це ж основа основ, яку всі розуміють.

Я: То може ти розповіси нам, що ж воно таке? Почнімо з аналізу класів еквівалентності.

Легковайті Тестущенко: Тю, я ж не ботан якийсь, зараз загуглю... Отже, ось що нам кажуть деякі ресурси з всемогутнього інтернету:

Клас еквівалентності (equivalence class) — набір даних, обробка яких призводить до одного й того ж результату.

Клас еквівалентності — це набір значень змінної, який вважається еквівалентним.

Суть дуже проста — всі вхідні тестові дані розбиваються на групи (класи), що викликають однакову поведінку програмного забезпечення.

Ну, думаю, цього досить, і так все зрозуміло.

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

Розглянемо простеньку функціональність:

Передумови: вік користувача — позитивне цілочисельне значення від 0 до 100, і валідується іншою функціональністю.

Функціонал: якщо вік користувача менший за 18 років — не дозволяти доступ до сайту. Якщо 18 і більше, то дозволяти користуватися сайтом.

Що ми тут маємо?

Легковайті Тестущенко: Очевидно, що два класи еквівалентності:

1. від 0 до 17 включно;
2. від 18 до 100 включно.

При будь-якому значенні від 0 до 17 включно система не повинна пропускати користувача, а отже будь-яке значення з першого класу повинно призводити до одного й того ж результату — не пропускати користувача. Те ж саме справедливо і для другого класу. То ж все вірно в інтернеті з визначеннями.

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

const isAccessAllowed = (age: number): boolean => {

    return age > 17;

}

І що ж в результаті? Скільки нам буде потрібно тестів, щоб перевірити функціонал за цією технікою тестування?

Легковайті Тестущенко: Ну, мінімум, два тести, по одному значенню з кожного класу, наприклад 8 та 50 років.

Я: Ти кажеш «мінімум два тести». Отже, може бути і максимум? Що ти маєш на увазі?

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

Я: Он як! То ж якщо будемо мати час — будемо тестити скільки влізе, як ні — обмежимось двома?

Легковайті Тестущенко: Ну, якость так...

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

Легковайті Тестущенко: Ага, має сенс... Зрозумів.

Я: А давай тоді ще один приклад:

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

Функціонал: оскільки модель взуття лише одна, то базова ціна взуття одна, але в залежності від розміру застосовується націнка: немає націнки на взуття від 38 до 41 розміру, 10% — на взуття від 42 до 45 розміру, 20% — на взуття від 46 до 50 розміру.

Легковайті Тестущенко: Та все те ж саме! Не мороч мені голову! Буде три класи:

1. 38 — 41;
2. 42 — 45;
3. 46 — 50.

Я: Тобто, за умов техніки еквівалентного розділення, ти б взяв лише три значення для перевірки, і виконав лише три тести?

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

Я: А якщо я тобі скажу, що можливий такий варіант, що обов’язкових перевірок треба буде зробити не 3, а 13 — тобто, по одній для кожного розміру.

Легковайті Тестущенко: Що за чухня! Навіщо? У вимогах же чітко сказано, що кожні з діапазонів розмірів повинні призводити до свого результату, що повністю відповідає визначенню класів еквівалентності.

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

Легковайті Тестущенко: Ох, йой...

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

Замість висновку

Щоб правильно аналізувати і використовувати техніки тест-дизайну, потрібно знати і розуміти, на якому підґрунті стоїть основа реалізації, а у випадку розробки ПО — це код або архітектурні рішення. А також, якщо ви вже точно і правильно вирахували класи еквівалентності, то не треба перевантажувати свої перевірки додатковими непотрібними тестами, просто аби «про всяк випадок».

Дякую за увагу. В наступній статті поговоримо про «проблеми» з аналізом граничних значень.