Ця стаття не містить посилань на джерела. Ви можете допомогти поліпшити цю статтю, додавши посилання на надійні (авторитетні) джерела. Матеріал без джерел може бути піддано сумніву та вилучено. (грудень 2022)

Ця стаття містить перелік посилань, але походження окремих тверджень залишається незрозумілим через брак внутрішньотекстових джерел-виносок. Будь ласка, допоможіть поліпшити цю статтю, перетворивши джерела з переліку посилань на джерела-виноски у самому тексті статті. Зверніться на сторінку обговорення за поясненнями та допоможіть виправити недоліки. (грудень 2022)

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

Під тест кейсом йдеться про наступну структуру: Action > Expected Result.

Тестові випадки, на відміну від чек-листів, не має поля «фактичний результат».

Тест кейси поділяються за очікуваними результатами на позитивні та негативні:

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

Якісний тестовий сценарій включає в себе:

• Опис (англ. description) — відображає мету перевірки;
• Передумова (англ. preconditions) — список дій, які приводять систему в стан необхідний для основної перевірки;
• Кроки (англ. steps) — метод виконання тесту, описаний покроково;
• Очікуваний результат (англ. expected result) — передбачена поведінка системи після проходження по кроках;

PostCondition - список дій, що переводить систему в початковий стан (стан до проведення тесту) і є не обов'язковою частиною.

• Відсутність залежності один від одного — оскільки тести можуть доповнюватися, змінюватися, втратити свою актуальність і бути видаленими. Крім того, взаємозв'язок може ввести в оману, що робота продукту відповідає очікуванням.
• Чіткі формулювання та висока ймовірність виявлення помилки;
• Наявність детальної та не надлишкової інформації — якщо перевірці підлягає процес авторизації, тест-кейс має містити логін та пароль.
• Легка діагностика помилок — виявлена помилка має бути очевидна.
• Дослідження відповідної (безпосередньо тієї, що потрібно) області додатка, виконання потрібних дій.

• Тестування програмного забезпечення
• Тест дизайнер
• Тест Архітектор