Дуже часто зустрічаються тест-кейси, в яких не повністю описаний процес тестування тієї чи іншої функції.
Будь-який тест-кейс повинен містити мінімально необхідну (і в той же час достатню) кількість інформації. Існує «золота середина» по відношенню до обсягу інформації в тест-кейсах. Якщо тест-кейс містить багато зайвої (другорядної) інформації – це уповільнює процес читання, розуміння і проходження самого тест-кейса. І навпаки, якщо інформації дуже мало – це призводить до непорозумінь, що саме необхідно зробити для того, щоб пройти тест-кейс.
Основні атрибути тест-кейса:
- «Передумови» – містить опис дій, які необхідно виконати, але прямого відношення до перевірки вони не мають.
- «Кроки» – містить опис дій, необхідних для перевірки.
- «Очікуваний результат» – сама перевірка: що ми очікуємо отримати після виконання кроків.
Якщо заповнення кроків і очікуваного результату є обов'язковим, то передумови заповнюються тільки при необхідності. Але при проходженні наших курсів даний пункт є обов'язковим атрибутом тест-кейсів.
Передумови в поєднанні з кроками повинні бути достатньо інформативні і містити всі необхідні дії від запуску додатка до деталізації роботи об'єкта тестування. Дуже часто зустрічаються тест-кейси, в яких відсутні деякі кроки чи важлива інформація в попередніх умовах. Очікуваний результат також повинен бути описаний досить докладно.
Розглянемо приклад:
Приклад 1
| Неправильний варіант | Правильний варіант |
|
Неправильний варіант
Передумови: Додаток запущено, користувач знаходиться на екрані з налаштуваннями. Помилка: Інформація про те, що користувач авторизований, в даному випадку є обов'язковою. Кроки:
Очікуваний результат: Користувач не авторизований. Помилка: Крім того, що користувач переходить в статус «не авторизований», ми також очікуємо автоматичний перехід на екран авторизації. |
Правильний варіант
Передумови: Додаток запущено, користувач авторизований і знаходиться на екрані з налаштуваннями. Кроки:
Очікуваний результат: Користувач не авторизований, відкривається екран авторизації. |
Крім цього, тест-кейси повинні бути описані в достатній мірі узагальнено. Якщо не дотримуватися цього принципу, то після кожної найменшої правки в додатку або на сайті знадобиться вносити відповідні зміни в тест-кейси.
Приклад 2
| Неправильний варіант | Правильний варіант |
|
Неправильний варіант
Передумови: Користувач авторизований і знаходиться на сайті http: //домен.юа. Помилка: Не бажано вказувати адресу сайту, оскільки тестування сайту може виконуватися на різних тестових майданчиках. Це можуть бути як продакшн, так і тестові майданчики розробників. Кроки:
Помилка: Якщо це не ускладнює розуміння кроків, то краще не вказувати точну назву кнопки, а описати її в більш загальному форматі (наприклад, по функціональному призначенню). В цьому випадку, якщо кнопку перейменують, або якщо перемкнути сайт на іншу мову, то поточний тест-кейс буде як і раніше актуальним без будь-яких змін. Очікуваний результат: Користувач не авторизований. |
Правильний варіант
Передумови: Користувач знаходиться на сайті і авторизований. Кроки:
Очікуваний результат: Користувач не авторизований. |
Також тест-кейс повинен бути логічно завершеним. Так як він створюється ще до знайомства з продуктом, тестувальник описує цілісну роботу певного функціоналу. Наприклад, описуючи функцію відновлення пароля, кейс повинен закінчуватися на успішній зміні пароля, а не відправкою листа з посиланням для зміни пароля.
Тренуйтеся, складайте грамотні тест-кейси.
У вас все вийде!
