Тестовий випадок (Test Case)

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

Під тест кейсом розуміється структура вигляду:

Action > Expected Result > Test Result

PreConditions — Список дій, які приводять систему до стану придатному для проведення основної перевірки. Або список умов, виконання яких говорить про те, що система знаходиться в придатному стані для проведення основного тесту.

Test Case Description — Список дій, що переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити вивід про задоволення реалізації, поставленим вимогам

PostConditions — Список дій, що переводять систему в первинний стан (стан до проведення тесту - initial state)

Примітка: Post Conditions не є обов'язковою частиною. Це швидше за все - правило хорошого тону: "насмітив - прибери за собою". Це особливо актуально при автоматизованому тестуванні, коли за один прогін можна наповнити базу даних сотнею або навіть тисячею некоректних документів.

Приклад тест кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3

У приведеному прикладі кінцева перевірка - В3. Це означає, що саме вона є ключовою. Значить, A1 і А2 - це дії приводять систему в стан придатний до тестування. А В1 і В2 - умови того, що система знаходиться в змозі придатному для тестування.

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

Тепер відповімо на питання: "Чому дане розбиття зручно використовувати?"

Відповідь: кінцева перевірка одна, тобто у випадку якщо тест провалений (test failed) буде відразу ясно із-за чого. Оскільки якщо провальними виявляться перевірки В1 і/або В2, то тест кейс буде заблокований (test blocked), через те, що функцію не можливо привести в стан придатний для проведення тестування, але це не означає, що тестована функція не працює.

Деталізація опису тест кейсів

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

Приклад тест кейса :

Назва: Перевірка відображення сторінки

Дія: Відкрити сторінку "Вхід в систему"

Перевірка: Перевірте, що сторінка, що відображається, відповідає сторінці на картинці 1 (і прикладаємо зображення сторінки "Вхід в систему")

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

Для того, щоб команда тестування працювала згуртовано і не відволікалася по питаннях оформлення тест кейсів, у всіх повинен бути єдиний шаблон або підхід до їх написання. Те, що пропонуємо ми - це структура PreConditions, Test Case Description, PostConditions, і вже ваше особисте рішення - користуватися цією структурою або придумати свій "велосипед".