> For the complete documentation index, see [llms.txt](https://swit-school.gitbook.io/qa-book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://swit-school.gitbook.io/qa-book/testuvannya-igor/dokumentaciya-testuvalnika/test-cases.md).

# Test cases

Ще однією обов'язковою сутністю, з якою зіткнеться кожен тестувальник, є Test Case (Тестовий випадок).

**Test Case** – це тестовий артефакт, суть якого полягає у виконанні деякої кількості дій та/або умов, необхідних для перевірки певної функціональності програмної системи, що розробляється.

<figure><img src="https://lh3.googleusercontent.com/7nsF_mA6_igw-vOPafZEW9U2b7Sg0NMNtK0eKEeRD8fPa9yX57vst-rXB4ZOyG_D7ssQxxw1FJO_4Dz2LshMZUNo_j0LtirmYWf0bZUyRhx3evT9BQtlmc0G5e_SI5NtNcTvVPqSxLxFytsv7UTjyj4Frw=s2048" alt=""><figcaption></figcaption></figure>

Структура цього артефакту полягає в «трійці»:

Дія, що виконується ( Action ) – Очікуваний результат ( Expected result ) – Фактичний результат (Test  result ).

Саме тестовий випадок складається з 3 частин (типова структура):

* **PreConditions (Передумови)** – або список кроків, які приводять систему, що перевіряється, в стан, придатний для тестування, або список перевірок умов того, що система вже перебуває в необхідному стані.
* **Test Case Description (Опис тестового випадку)** – список дій, за допомогою яких здійснюється основна перевірка функціоналу (після якої і звіряється фактичний результат з очікуваним).
* **PostConditions (Постумова)** – список дій, які повертають систему до початкового стану.

<figure><img src="https://lh4.googleusercontent.com/CEWTpEGHoRW6AKdQ4bl-GJoyoRX1rhVE5sJ-kpNow_hNtIBZ-VmBAaxzixtsFzxpjxLdqrvYAvg8yf-Ang7rECE8EjI4i1jD2PBIxJD7MTl6RbFn3AmRb3FKTK_XgccyEJwKh-DQD-577g4_48dUBf0" alt=""><figcaption></figcaption></figure>

Спосіб опису тест кейсів та їх структура може в кожній компанії чи команді бути різним: мати різні глибини опису необхідних дій та результатів, мати різні структурні складові. Але, хороша структурованість і висока зручність шаблонів тестових випадків, може скоротити час рутинних заповнень форм і підвищити ефективність команди в цілому.

Розглянемо наступну структуру тест кейса:

<figure><img src="https://lh4.googleusercontent.com/UJC9tuc6xujNUsVYUMuIz8XlpNBWBMoCRWiROZp3Ic_68tcVnQbdPlc0WwbePYO0PPcfTv5sARy-XXEPeNF2Px1dhYUiGe3ekp_Yo4Lrpt7Vu_DcXQOwsxbfp4KNlj7kee5cnv-XPmTsJrSI_20hkts" alt=""><figcaption></figcaption></figure>

**Summary** - опис того, що саме будемо перевіряти

**Precondition** - список кроків, які приводять систему, що перевіряється, в стан, придатний для тестування, або список перевірок умов того, що система вже перебуває в необхідному стані.

**Steps** - детальні кроки перевірки, які повинні привести нас до очікуваного результату.

**Expected result** - очікуваний результат після виконання кроків (згідно вимог).

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