Як писати хороші тест-кейси та баг-репорти

Тест-кейс

Що робить тест-кейс хорошим

Хороший тест-кейс — документ, який будь-який інший тестувальник може виконати без додаткових запитань і отримати той самий результат.

Структура тест-кейсу

Поле	Опис	Приклад
TC ID	Унікальний ідентифікатор	AUTH-TC-001
Назва	[Дія] + [умова] + [об'єкт]	Успішний вхід з валідними email та паролем
Пріоритет	High / Medium / Low	High
Передумови	Точний стан системи до початку	Акаунт зареєстрований і активований
Тестові дані	Конкретні значення	user@test.com / Pass123!
Кроки	Нумерований список, 1 крок = 1 дія	1. Ввести email...
Очікуваний результат	Вимірюваний стан системи	Редирект на /dashboard
Фактичний результат	Заповнюється при виконанні	Pass / Fail + опис

Поганий vs хороший тест-кейс

❌ Поганий

Назва: Тест логіну
Передумови: —
Кроки:
  1. Відкрити сайт
  2. Натиснути логін
  3. Ввести дані
  4. Перевірити результат
Очікуваний результат: Логін працює

Проблеми:

Назва не говорить що саме тестується
Немає передумов — невідомо який акаунт потрібен
«Ввести дані» — які саме?
«Логін працює» — це що? Де опиняється користувач?

✅ Хороший

TC ID: AUTH-TC-001
Назва: Успішний вхід з валідними email та паролем
Пріоритет: High

Передумови:
  - Акаунт user@test.com / Pass123! зареєстрований і активований
  - Відкрита сторінка /login

Тестові дані:
  - Email: user@test.com
  - Password: Pass123!

Кроки:
  1. У поле Email ввести: user@test.com
  2. У поле Password ввести: Pass123!
  3. Натиснути кнопку «Увійти»

Очікуваний результат:
  - Виконується редирект на /dashboard
  - Відображається «Привіт, user@test.com»
  - Сесія активна (токен у cookies)

Правила написання кроків

Один крок = одна атомарна дія
Завжди: дієслово + об'єкт + значення
✅ Натиснути кнопку «Зберегти»
❌ Зберегти
✅ У поле «Ім'я» ввести: Іван
❌ Ввести ім'я

Правила очікуваного результату

Завжди вимірюваний і однозначний
✅ Відображається повідомлення «Пароль змінено успішно»
❌ Все ок
✅ URL змінюється на /dashboard
❌ Перехід на нову сторінку

Баг-репорт

Мета баг-репорту

Розробник повинен без жодного запитання:

Відтворити баг
Зрозуміти що пішло не так
Зрозуміти що повинно було статись

Золоте правило: Уяви, що передаєш репорт незнайомому розробнику о 23:00 перед релізом.

Структура баг-репорту

Поле	Опис
ID	Унікальний номер (BUG-0142)
Заголовок	де + що відбувається + наслідок
Severity	Технічна серйозність (визначає QA)
Priority	Терміновість виправлення (визначає менеджер)
Status	Open / In Progress / Fixed / Closed / Reopen
Середовище	Staging / Production + версія
Браузер/ОС	Chrome 124 / Windows 11
Передумови	Стан системи до відтворення
Кроки відтворення	Мінімальна послідовність
Фактичний результат	Що сталося (факти, не оцінки)
Очікуваний результат	Що мало статися
Додатково	Скріншот, відео, логи, HAR

Приклад хорошого баг-репорту

ID: BUG-0142
Заголовок: Кнопка «Оплатити» активна при порожньому кошику — HTTP 500

Severity: Critical
Priority: High
Status: Open

Середовище: Staging v2.14.3
Браузер: Chrome 124 / Windows 11

Передумови:
  - Авторизований акаунт user@test.com
  - Кошик порожній (жодного товару)
  - Відкрита сторінка /cart

Кроки відтворення:
  1. Перейти на /cart при порожньому кошику
  2. Переконатись що список товарів порожній
  3. Натиснути кнопку «Оплатити»

Фактичний результат:
  Сервер повертає HTTP 500.
  У консолі: TypeError: Cannot read properties of undefined (reading 'items')
  Сторінка зависає, користувач не отримує повідомлення про помилку.

Очікуваний результат:
  Кнопка «Оплатити» неактивна (disabled) при порожньому кошику.
  АБО відображається: «Кошик порожній, додайте товари перед оплатою».

Додатково:
  - Відтворюється на 100%
  - Скріншот і HAR-файл додано
  - Пов'язаний тест-кейс: CART-TC-008
  - Регресія: у v2.13.0 кнопка була задізейблена

Severity vs Priority

Це різні поняття — найпопулярніше питання на співбесіді.

	Severity	Priority
Що означає	Наскільки серйозна проблема технічно	Наскільки терміново виправляти
Хто визначає	QA тестувальник	Менеджер / Product Owner

Рівні Severity

Рівень	Опис	Приклад
Blocker	Система повністю непрацездатна	Додаток не запускається
Critical	Основна функція зламана, обхідного шляху немає	Оплата завершується з помилкою
Major	Важлива функція некоректна, є workaround	Сортування дає неправильний порядок
Minor	Незначне відхилення від вимог	Фільтр не скидається кнопкою Reset
Trivial	Косметичні дефекти	Опечатка в тексті

Приклади коли Severity ≠ Priority

Ситуація	Severity	Priority	Чому
Опечатка в назві компанії на головній	Trivial	High	Бачать всі клієнти
Критичний баг в рідкісній функції	Critical	Low	Торкається 0.1% юзерів
Зламаний імпорт застарілого формату	Major	Low	Відкласти до наступного спринту

Типові помилки в баг-репортах

❌ «Не працює кнопка»

Не вказано що сталось, де, за яких умов. Правильно: що очікували vs що отримали.

❌ Кілька багів в одному репорті

«Кнопка не працює, текст обрізається і фото не завантажується» — це три окремих репорти. Один баг = один звіт.

❌ Відсутні передумови

«Зайти на сторінку і натиснути» — з яким акаунтом? З якими правами? Без цього розробник відповість «не відтворюється».

❌ Оціночні судження замість фактів

❌ «Система дуже повільна»
✅ «Відповідь сервера 8400мс при нормі ≤2000мс»
❌ «Відображається якась помилка»
✅ «Відображається текст: Error code 403»

❌ Нерепродукований баг без відсотку

Якщо баг відтворюється не завжди — вказуй: «Відтворюється у ~3 з 5 випадків».

Формула хорошого заголовку баг-репорту

[де] + [що відбувається] + [наслідок]

Приклади:

✅ Сторінка /cart: кнопка «Оплатити» активна при порожньому кошику → HTTP 500
✅ Форма реєстрації: поле Email приймає рядок без @ → акаунт створюється
✅ Мобільна версія: кнопка «Далі» перекрита клавіатурою на iOS → недоступна
❌ Помилка на сторінці
❌ Баг з кнопкою

Питання на співбесіді

«Яка різниця між severity і priority?»

Severity — технічна серйозність дефекту, визначає QA. Priority — терміновість виправлення, визначає менеджер. Вони можуть не збігатися: косметична помилка на головній сторінці має Low severity, але High priority — бо її бачать всі клієнти.

«Що обов'язково повинно бути в баг-репорті?»

Заголовок (де+що+наслідок), середовище і версія, передумови, кроки відтворення, фактичний і очікуваний результат, severity і priority. Плюс скріншот або відео.

«Що таке хороший тест-кейс?»

Тест-кейс, який будь-який тестувальник може виконати без додаткових запитань і отримати той самий результат. Конкретні тестові дані, атомарні кроки, вимірюваний очікуваний результат.