Типові помилки при оформленні тест-кейсів на курсах

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

Топ-помилок під час опису тест-кейсів

1. Тема тест-кейса описана не за принципом «Що перевіряється? Де перевіряється? З яким типом даних перевіряється?»

Відповідь на питання «Де перевіряється?» можна пропустити, але за умови, що функціонал доступний тільки в одному місці. Частина «З яким типом даних перевіряється» не потрібно вказувати, якщо в функціоналі не потрібне введення даних.

Наприклад: Authorization on the site using invalid data. 

У цьому випадку частина «Де перевіряється?» можна упустити, так як авторизація на сайті доступна тільки в одному місці. Тема тест-кейса стає коротшою без втрати важливої ​​інформації: Authorization using invalid data.

2. Опис кроків в передумовах.

В передумовах не потрібно описувати послідовність дій користувача (кроки). Досить зазначити, на якій сторінці знаходиться користувач або яка форма відкрита (її назва). Але не потрібно вказувати посилання на форму або сторінку, так як її адреса може змінитися в процесі розробки.

Також в передумовах необхідно описувати критерії, які не належать до функціоналу, але обов'язкові для виконання (чи зареєстрований користувач, авторизований, в який стан повинна бути приведена система тощо).

3. Не вказано тип даних, що вводяться.

У кроках необхідно вказувати тип даних, що вводяться (валідні, невалідні). У другому випадку обов'язково повинні бути наведені приклади. Наприклад, для поля введення електронної пошти невалідними будуть тільки цифри, спецсимволи, без @, без домену. Ця інформація вказується для прискорення перевірки тест-кейсу.

4. Тест-кейс складається з одного кроку.

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

Також в кроці потрібно описувати одну дію, не потрібно об'єднувати кілька дій в одному кроці.

5. Описано фактичний результат замість очікуваного.

Тест-кейси зазвичай оформлюються на етапі тест-дизайну, ДО знайомства з тестованим продуктом. Описувати перевірки необхідно виходячи з того, як певний функціонал ПОВИНЕН працювати. З цієї ж причини в тест-кейсах не вказуються посилання на баг-репорти.

6. Вказано посилання на сайт в першому кроці.

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

7. Дублювання нумерації кроків.

В системі TestRail кроки нумеруються автоматично, тому не варто дублювати нумерацію вручну.

8. Граматичне оформлення тест-кейса.

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

У тест-кейсах, як і в баг-репортах, передумови і результати потрібно описувати повними реченнями (підмет + присудок), щоб максимально точно передати суть.

9. Незавершений тест-кейс.

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

10. Дублікати тест-кейсів.

Досить часто зустрічається така помилка, коли для одного функціоналу з одним видом даних створюється кілька тест-кейсів. Наприклад: в одному кейсі з перевірки авторизації вводиться невалідна електронна пошта і валідний пароль. У другому навпаки – валідна пошта і невалідний пароль. Для перевірки одного функціоналу досить два тест-кейса – з валідними і невалідними даними. Решта ж просто повторюють суть перевірки, тому закриваються як дублікати.

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