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

1. ID (номер)
2. Name (ім’я)
3. Preconditions (умови і параметри)
4. Steps (кроки до відтворення)
5. Expected result (очікуваний результат)
6. Postconditions (постумови)

Проблемні тестові випадки:

• Які залежні один від одного (наприклад, очікується, що частина кроків виконана в попередньому test case, є посилання на інші test cases)
• З нечітким формулюванням кроків
• З нечітким формулюванням ідеї або очікуваного результату

Test cases можуть бути:
– Позитивні – використовуються тільки коректні дані і перевіряють, чи правильно додаток виконує функцію
– Негативні – використовуються як коректні, так і некоректні дані (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що функція не виконується при спрацьовування валідатора.

Основні стани тест кейсу:

• Created (створений)
• Modified (змінений)
• Retired (більше не дійсний)

Основні стани проходження тест кейсу:

• No run (не запущено)
• Passed (пройдено)
• Failed (помилка)
• Blocked (заблоковано)
• Not Completed (не завершено)

Система відстеження помилок (багтрекінгова система, bugtracking system) – програма, розроблена з метою допомоги розробникам ПЗ враховувати і контролювати помилки (баги), знайдені в програмах, побажаннях користувачів, а також стежити за процесом усунення цих помилок і виконання або невиконання побажань.

Головний компонент такої системи – база даних, що містить відомості про виявлені дефекти:

1. Номер (ідентифікатор об’єкта)
2. Дата і час, коли був виявлений дефект
3. Хто повідомив про дефект
4. Хто відповідальний за усунення дефекту
5. Короткий опис проблеми (обов’язкове поле)
6. Критичність дефекту (обов’язкове поле) і пріоритет рішення
7. Опис кроків для виявлення дефекту (відтворення неправильної поведінки програми) (обов’язкове поле)
8. Очікуваний результат (обов’язкове поле)
9. Фактичний результат (обов’язкове поле)
10. Обговорення можливих рішень і їх наслідків
11. Статус дефекту
12. Версія продукту, в якій дефект був знайдений
13. Версія продукту, в якій дефект виправлений
14. Скріншот

Серйозність (Severity) – це атрибут, що характеризує вплив дефекту на працездатність програми
Блокуюча (Blocker) – розробка або використання продукту неможливо. Необхідно негайне виправлення проблеми.
Критична (Critical) – серйозні проблеми (не працює критичний блок функціоналу, спостерігаються серйозні помилки, пов’язані з втратою даних тощо)
Значна (Major) – проблема, пов’язана з важливим функціоналом продукту.
Незначна (Minor) – проблема пов’язана з другорядним функціоналом продукту або є легкий обхідний шлях для цієї проблеми.
Тривіальна (Trivial) – проблема косметичного рівня («недопрацьований» інтерфейс: друкарські помилки, різнобій з кольорами)

Пріоритет (Priority) – це атрибут, який вказує на черговість виконання завдання або усунення дефекту. Чим вище пріоритет, тим швидше потрібно виправити дефект.
Високий (High) – помилка повинна бути виправлена якомога швидше, тому що її наявність є критичною для проекту.
Середній (Medium) – помилка повинна бути виправлена, її наявність не є критичною, але вимагає обов’язкового рішення.
Низький (Low) – помилка повинна бути виправлена. Її наявність не є критичною, і не вимагає термінового вирішення.

Порядок виправлення помилок з їх пріоритетами:
High -> Medium -> Low

Життєвий цикл дефекту:
Система відслідковування помилок використовує один з варіантів «життєвого циклу» помилки, стадія якого визначається поточним станом, або статусом, в якому знаходиться помилка.

Типовий цикл дефекту (Defect cycle):
Новий (New) – дефект зареєстрований тестувальником
Призначено (Open) – призначений відповідальний за виправлення дефекту
Вирішений (Fixed) – дефект переходить назад в сферу відповідальності тестувальника. Як правило супроводжується резолюцією, наприклад:
Виправлено (виправлення включені у версію таку-то),
Дубль (повторює дефект, вже знаходиться в роботі),
НЕ виправлено (працює відповідно до специфікації, має занадто низький пріоритет, виправлення відкладено до наступної версії і т.п.)
Відхилений (Rejected) – запит додаткової інформації про умови, в яких дефект проявляється, або не згоду з тим, що виявлена поведінка системи дійсно являєтся дефектом.
Відкрито повторно (Reopen) – дефект знову знайдений в іншій версії.
Закритий (Closed) – використовується системою для закриття вирішених завдань.

Принцип: «Де? Що? Коли?»
Де?: У якому місці інтерфейсу користувача або архітектури програмного продукту знаходиться проблема.
Що?: Що відбувається або не відбувається згідно специфікації або вашому уявленню про нормальну роботу програмного продукту. При цьому вказуйте на наявність або відсутність об’єкта проблеми, а не на його утримання (його вказують в описі).
Коли?: У який момент роботи програмного продукту, по настанню якої події або за яких умов проблема проявляється.

Наступна лекція