Як дізнатися, що написаних тест-кейсів достатньо?

Під час створення IT-продукту велику роль грає забезпечення якості – Quality Assurance (QA). Разом з іншими іструментами для усунення помилок та багів QA-інженери застосовують техніки тест-дизайну.

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

Які цілі написання тест-кейсів?

Наявність тест-кейсів дозволяє:

1. Структурувати та систематизувати підхід до тестування (без цього великий проєкт майже гарантовано приречений на провал).
2. Обчислювати метрики тестового покриття (test coverage metrics) та вживати заходів щодо його збільшення (тест-кейси тут є головним джерелом інформації).
3. Відслідковувати відповідність поточної ситуації плану (скільки приблизно знадобиться тест-кейсів, скільки вже є, скільки виконано із запланованої на даному етапі кількості тощо).
4. Збільшувати взаєморозуміння між замовником, розробниками та тестувальниками (тест-кейси часто більш наочно показують поведінку програми, ніж це відображено у вимогах).
5. Зберігати інформацію для тривалого використання та обміну досвідом між співробітниками та командами.
6. Проводити регресійне та повторне тестування (які без тест-кейсів було б взагалі неможливо виконати).
7. Підвищувати якість вимог (написання чек-листів та тест-кейсів – ефективні техніки тестування вимог).
8. Швидко вводити в курс справи нового співробітника, який нещодавно підключився до проєкту.

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

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

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

Один із підходів до оцінки та виміру тестового покриття – покриття вимог.

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

Цей показник розраховується за такою формулою:

Тестове покриття вимог =  (кількість вимог, що перевіряється тест-кейсами/загальна кількість вимог)*100%

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

Кожен зв'язок, створений між тест-кейсами та вимогами, називається матрицею відстеження.

Якщо проаналізувати такий зв’язок, можна легко отримати відповідь на такі запитання: 

• які вимоги перевіряються певними тестами?
• які вимоги потребують створення та/або редагування доступних тестів?

Деякі вимоги можуть містити непотрібні тест-кейси.

Метрика покриття вимог також має й свої недоліки:

1. Якщо не використовувати зв’язки між вимогами та тестами – неможливо виміряти покриття вимог. Тож треба бути обережними та виділяти час на такі заходи.
2. Можуть бути «білі плями» – вимоги, які не охоплені тестами, тому неможливо сказати, чи реалізована ця функціональність.
3. Потрібно переглядати тестові випадки щодня. Коли вимога змінюється, тест-кейси для цих вимог стають марними, вони більше нічого не перевіряють. Такі тест-кейси слід вилучати з тестового набору, і, звичайно, потрібен час, щоб ідентифікувати такі випадки.

Інші метрики, які використовуються для оцінки якості тест-кейсів:

• продуктивність підготовки тест-кейсів (Test Case Preparation Productivity): використовується для розрахунку кількості підготовлених тест-кейсів та зусиль (Effort), витрачених на їхню підготовку.

Продуктивність підготовки тест–кейсів = Кількість тест-кейсів/Зусилля, витрачені на підготовку тест-кейсів

• охоплення тестового дизайну (Test Design Coverage): відсоток покриття тест-кейсами вимог.

Охоплення тестового дизайну = (Загальна кількість вимог, відображених у тест-кейсах/Загальна кількість вимог)*100

• продуктивність виконання тестів (Test Execution Productivity): визначає кількість тест-кейсів, які можуть бути виконані за годину.

Продуктивність виконання тестів = Кількість виконаних тест-кейсів/Зусилля, витрачені на виконання тест-кейсів

• покриття виконаних тестів (Test Execution Coverage): призначене для вимірювання кількості виконаних тест-кейсів порівняно з кількістю запланованих тест-кейсів.

Покриття виконаних тестів = (Загальна кількість виконаних тест-кейсів/Загальна кількість тест-кейсів,
які планувалося виконати)*100

• успішні тест-кейси (Test Cases Passed): для вимірювання відсотка пройдених успішно тест-кейсів.

Успішні тест–кейси = (Загальна кількість успішних тест-кейсів/Загальна кількість виконаних тест-кейсів)*100 

• неуспішні тест-кейси (Test Cases Failed): для вимірювання відсотка завалених тест-кейсів.

Неуспішні тест–кейси = (Загальна кількість неуспішних тест-кейсів/Загальна кількість виконаних тест-кейсів)*100 

• заблоковані тест-кейси (Test Cases Blocked): для вимірювання відсотка блокованих тест-кейсів.

Заблоковані тест–кейси = (Загальна кількість заблокованих тест-кейсів/Загальна кількість виконаних тест-кейсів)*100 

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

Хороший тест-кейс відповідає наступним характеристикам:

1. Відсутні залежності один від одного (оскільки тести можуть доповнюватися, змінюватись, втрачати свою актуальність і видалятися, крім того, взаємозв'язок може ввести в оману, ніби робота продукту відповідає очікуванням).
2. Чіткі формулювання, грамотна технічна мова та висока ймовірність виявлення помилки.
3. Послідовний та зрозумілий опис кроків та результатів, відсутність «прогалин» в інформації.
4. Наявність детальної, але не надмірної інформації (наприклад, якщо перевірці підлягає процес авторизації, тест-кейс має містити логін та пароль).
5. Легка діагностика помилок (виявлена помилка має бути очевидною).

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

Як же тоді писати тест-кейси без вимог?

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

• Задати запитання продакт-менеджерам/розробникам. Не потрібно очікувати повний список деталей, але вони можуть стати чудовим ресурсом для роз’яснень. Краще задавати конкретні запитання. Це допоможе швидше отримати відповідь і зменшить потребу у подальших запитаннях. Наприклад, можна запитати: «Як має працювати ця кнопка?» Але краще сформулювати це так: «Коли користувач натискає цю кнопку, до якого розділу він має перейти?»

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

• Обміркувати всі можливі взаємодії з обраною функцією. Слід подивитись на кожну кнопку, яку можна обрати, кожну можливу комбінацію параметрів. Навіть якщо це те, що користувач навряд чи зробить, це добре додати в тест-кейс. Наприклад, «Якщо користувач вводить цифри в поле імені та намагається зберегти, має виникнути помилка».

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

• Надати підсумок того, що буде тестуватися, продакт-менеджеру. Під час написання тест-кейсів без вимог, можна завершити тестування на основі припущень, які відрізняються від очікувань продакт-менеджера, тому має сенс тримати його у курсі.
• Мати стандартний список очікувань для будь-якої функції. Навіть якщо список короткий, є вимоги, які можна очікувати для будь-якої функції. Наприклад, якщо це додаток – він має працювати як на iOS, так і на Android. Або якщо це веб-сайт, він має працювати в усіх основних десктопних і мобільних браузерах. Можна також включити загальні стандарти доступності. Наприклад, «Людина, яка є сліпою або глухою, повинна мати можливість використовувати цю функцію». Або якщо програмне забезпечення має платні рівні, можливо, лише користувачі преміум-класу мають мати доступ до нових функцій.

Написання тест-кейсів в даний момент користується попитом як обов'язковий інструмент для забезпечення якості проєкту. Зокрема, використовується як одна з форм надання важливої інформації про якість продукту внаслідок проведення робіт із тестування. Чітко визначені тест-кейси дозволяють багаторазово запускати одні й ті самі тести, застосовувати для версій програмного забезпечення, що послідовно змінюються. А ще відстежувати регресивні помилки ПЗ – тобто ті, що повторюються та погіршують якість продукту. Хороший тест-кейс – це поєднання лаконічності, конкретики та охайного оформлення. Наостанок виділимо п'ять властивостей якісно написаного тест-кейсу: чіткість формулювань, послідовність викладу, помірна деталізація кроків, грамотна технічна мова та наявність базових атрибутів.