Тест-кейс: що це, структура, приклад і шаблон

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

Що таке тест-кейс простими словами

Під час аналізу тестування команда вирішує, «що перевіряти». Відповідь — умова тестування, тобто окремий аспект системи, наприклад «вхід за email і паролем». Тест-кейс відповідає на інше питання: «як саме перевірити». За програмою ISTQB Foundation Level (станом на жовтень 2026 року чинна версія — 4.0.1), умови тестування перетворюють на тест-кейси під час проєктування тестів, а згодом кейси об’єднують у процедури й набори для прогону.

Зазвичай тест-кейси пише QA-інженер або тест-аналітик. У підході ATDD їх складають ще до розробки функції — на основі критеріїв прийняття з історії користувача (user story).

Високорівневі й низькорівневі тест-кейси

Програма ISTQB для тест-аналітиків (CTAL-TA 4.0) розрізняє два рівні деталізації:

  • високорівневий, або логічний, кейс показує, що перевіряють, без конкретних значень: «вхід зареєстрованого користувача з правильним паролем»;
  • низькорівневий, або конкретний, кейс містить точні дані, дії та очікуваний результат: яку адресу ввести, який пароль, що з’явиться на екрані.

Здебільшого спершу пишуть логічні кейси, а з кожного роблять один або кілька конкретних.

Структура тест-кейсу: обов’язкові поля

Єдиного формату немає: за CTAL-TA, вигляд і деталізація кейсів залежать від проєкту, а погоджує їх команда тестування. Базовий набір поєднує складники з визначення ISTQB і службові поля:

  1. ID — унікальний ідентифікатор, наприклад TC-LOGIN-001. За ним на кейс посилаються у звітах і баг-репортах.
  2. Назва (Title) — коротко, що саме перевіряють. Добра назва пояснює мету кейсу, навіть якщо його не відкривати.
  3. Передумови (Preconditions) — стан системи й тестового середовища до старту: які дані вже є, під яким користувачем працюють, який браузер чи версія застосунку.
  4. Тестові дані (Test Data) — конкретні значення, які вводить тестувальник.
  5. Кроки (Steps) — дії по черзі; кожен крок — одна дія, після якої видно реакцію системи.
  6. Очікуваний результат (Expected Result) — що має статися, якщо програма працює правильно. Його беруть із вимог, макетів чи user story, а не з того, як система поводиться зараз.
  7. Пріоритет (Priority) — наскільки важлива перевірка. Від нього залежить порядок прогону, коли часу на все не вистачає.

Додаткові поля

  • Кінцеві умови (Postconditions) — стан системи після тесту і що треба прибрати: вийти з облікового запису, видалити створене замовлення.
  • Посилання на вимогу — номер історії користувача чи завдання. Так видно, які вимоги вже покриті тестами.
  • Тип і рівень — наприклад, функціональний, регресійний чи смоук-тест; end-to-end, API чи юніт.
  • Фактичний результат (Actual Result) і статус — їх заповнюють під час прогону: пройдено, не пройдено, заблоковано.

Приклад тест-кейсу для форми входу

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

ID: TC-LOGIN-001
Назва: Вхід зареєстрованого користувача з правильним паролем
Пріоритет: високий
Вимога: US-12 «Вхід за email і паролем»
Передумови: обліковий запис qa.user@example.com існує й активний; користувач не авторизований; у браузері Chrome відкрито сторінку входу.
Тестові дані: email — qa.user@example.com; пароль — Test-Pass-2026.
Кроки:
1. Ввести email у поле «Email».
2. Ввести пароль у поле «Пароль».
3. Натиснути кнопку «Увійти».
Очікуваний результат: відкривається сторінка «Мій кабінет», угорі видно email користувача, повідомлень про помилку немає.
Кінцеві умови: користувач авторизований; після тесту вийти з облікового запису.

Позитивні й негативні тест-кейси

Кейс вище — позитивний: він підтверджує, що з коректними даними система працює як слід. Негативний кейс перевіряє, що буде, коли системою користуються не за призначенням: вводять хибні дані, лишають обов’язкові поля порожніми, порушують порядок дій. У розділі про ATDD програма ISTQB радить спершу писати позитивні кейси, а вже потім негативні.

Негативні кейси для тієї самої форми:

  • TC-LOGIN-002. Правильний email і неправильний пароль: вхід не виконано, з’являється загальне повідомлення «Неправильний email або пароль».
  • TC-LOGIN-003. Email, якого немає в системі: те саме загальне повідомлення, без підказки, що такого облікового запису не існує.
  • TC-LOGIN-004. Обидва поля порожні: біля полів з’являються підказки про обов’язкове заповнення, вхід не виконано.
  • TC-LOGIN-005. Email без символу @: з’являється повідомлення про неправильний формат адреси.

Кожен негативний кейс перевіряє одну помилку. Якщо поєднати хибний пароль і порожнє поле email, буде незрозуміло, на що саме зреагувала система. CTAL-TA теж радить невеликі кейси: так легше знайти причину збою, а падіння одного кейсу не блокує наступних.

Як придумати тест-кейси: техніки тест-дизайну

Перебрати всі можливі значення неможливо, тому кейси добирають за техніками проєктування тестів. Дві базові з програми Foundation Level:

  • Розбиття на класи еквівалентності. Дані ділять на групи, які система має обробляти однаково, і з кожної беруть одне значення: якщо воно виявило дефект, інші значення з тієї ж групи мали б виявити його теж.
  • Аналіз граничних значень. Перевіряють межі груп, бо саме на них розробники помиляються частіше. Якщо пароль під час реєстрації має містити від 8 до 64 символів, у варіанті з двома значеннями на кожну межу перевіряють довжину 7, 8, 64 і 65 символів.

Крім них, ISTQB описує тестування за таблицею рішень, тестування переходів між станами і техніки на основі досвіду: вгадування помилок, дослідницьке тестування, тестування за чек-листом.

Тест-кейс, чек-лист і баг-репорт: у чому різниця

Ці документи відповідають на різні питання: тест-кейс — «як перевірити», чек-лист — «що не забути перевірити», баг-репорт — «що зламалося і як це відтворити».

Тест-кейс

Детальна інструкція для однієї перевірки, яку можна повторити через місяць так само, як сьогодні. З таких кейсів збирають регресійні набори, а регресійне тестування ISTQB називає сильним кандидатом на автоматизацію.

Чек-лист

Перелік того, що треба перевірити, без детальних кроків. В українському глосарії ISTQB для нього вживають термін «контрольний список», а програма Foundation Level зазначає, що його пункти часто формулюють як питання і кожен має перевірятися окремо. Для форми входу:

  • Чи приховуються символи в полі пароля?
  • Чи працює вхід після натискання Enter?
  • Чи є на сторінці посилання для відновлення пароля?
  • Чи зберігається введений email після помилки?

Чек-лист швидше скласти, і за відсутності детальних кейсів він задає орієнтири. Але за ISTQB загальний чек-лист дає більшу варіативність: покриття може вийти ширшим, а повторюваність — нижчою. Тому критичні сценарії, які мають перевірятися щоразу однаково, краще описувати тест-кейсами.

Баг-репорт

Баг-репорт, або звіт про дефект, створюють, коли фактичний результат не збігся з очікуваним. За програмою Foundation Level, типовий звіт містить:

  • ID і коротку назву проблеми;
  • дату, автора, об’єкт тестування і середовище;
  • кроки відтворення, логи, знімки чи запис екрана;
  • очікуваний і фактичний результат;
  • серйозність дефекту і пріоритет виправлення;
  • статус і посилання, зокрема на тест-кейс, під час якого дефект знайшли.

Приклад зв’язку: якщо під час прогону TC-LOGIN-003 система відповідає «Користувача з таким email не знайдено», кейс отримує статус «не пройдено», а тестувальник створює баг-репорт із посиланням на нього. Таке повідомлення підказує, які адреси зареєстровані в сервісі, і OWASP застерігає саме від цього.

Як писати тест-кейси, щоб ними могли користуватися інші

CTAL-TA перелічує критерії якості тест-кейсів. Головні з них:

  • Точність. Кейс має лише одне тлумачення. Слова на кшталт «відповідний», «за потреби», «кілька» замініть конкретикою.
  • Зрозумілість. Кейс виконуватимуть і змінюватимуть не лише ви, тож пишіть зрозуміло для всіх учасників, але без пояснення очевидного. Складні кейси спрощуйте або діліть.
  • Повнота. Є всі потрібні поля, тестові дані й чіткий очікуваний результат. Формулювання «система працює коректно» неможливо порівняти з фактичним результатом.
  • Відстежуваність. Кейс пов’язаний із вимогою чи ризиком, тому його легко оновити, коли вимога зміниться.

Шаблон тест-кейсу

Скопіюйте шаблон у документ, таблицю чи систему управління тестуванням. У таблиці зручно зробити кожне поле колонкою, а кожен кейс — рядком.

ID: [префікс і номер, наприклад TC-CART-001]
Назва: [що перевіряємо, одним реченням]
Пріоритет: [високий / середній / низький]
Вимога: [номер історії користувача або завдання]
Передумови: [стан системи, наявні дані, користувач, середовище]
Тестові дані: [конкретні значення]
Кроки:
1. [дія]
2. [дія]
3. [дія]
Очікуваний результат: [що саме має статися]
Кінцеві умови: [стан після тесту, що прибрати]
Фактичний результат і статус: [заповнюють під час прогону]

Де вести тест-кейси

Для навчального проєкту вистачить таблиці в Google Sheets чи Excel. Коли кейсів багато, а прогони повторюються, зручніші системи управління тестуванням. Станом на жовтень 2026 року серед них є такі:

  • TestRail — окрема платформа, що збирає разом тест-кейси, дефекти й результати ручних і автоматизованих тестів; має двосторонню інтеграцію з Jira.
  • Qase — у картці кейсу є серйозність, пріоритет, тип, поведінка (позитивний, негативний чи деструктивний кейс), передумови й кінцеві умови. Кроки записують як дію, дані й очікуваний результат або у форматі Given/When/Then.
  • Zephyr від SmartBear — управління тестуванням усередині Jira: кейси пов’язують з історіями користувача, вимогами й дефектами, не виходячи з Jira.

Тарифи й умови доступу до цих сервісів змінюються, тож перевіряйте їх на сайтах розробників.

Що далі

Про спринти й історії користувача, з якими працюють тестувальники, читайте в матеріалі про Scrum простими словами. Якщо готуєтеся до першої роботи в QA, перегляньте питання на співбесіді QA Junior і гайд про резюме для IT без досвіду. Новини про навчання збираємо в розділі «Освіта», а про інструменти розробки — у розділі «Розробка».

Часті питання

Що таке тест-кейс простими словами?

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

Чим тест-кейс відрізняється від чек-листа?

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

Які поля має містити тест-кейс?

Базовий набір — ID, назва, передумови, тестові дані, кроки, очікуваний результат і пріоритет. Кінцеві умови, посилання на вимогу, тип і статус прогону додають залежно від домовленостей у команді.

Що таке негативний тест-кейс?

Це перевірка того, як система поводиться, коли нею користуються не за призначенням: вводять хибні чи порожні дані або порушують порядок дій. Очікуваний результат — коректна обробка помилки, наприклад зрозуміле повідомлення, а не збій програми.

Де писати тест-кейси?

Для старту вистачить таблиці, де кожне поле — окрема колонка. Коли кейсів багато, зручніші системи управління тестуванням, наприклад TestRail, Qase або Zephyr для Jira.