Види Тест Кейсiв. Стани Тест Кейсiв. Багтрекінгові системи. Серйозність і пріоритет дефекту. Життєвий цикл дефекту.

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

  1. ID (номер)
  2. Name (ім’я)
  3. Preconditions (умови і параметри)
  4. Steps (кроки до відтворення)
  5. Expected result (очікуваний результат)
  6. Actual result (фактичний результат)
  7. 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) – використовується системою для закриття вирішених завдань.

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

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

  1 comment for “Види Тест Кейсiв. Стани Тест Кейсiв. Багтрекінгові системи. Серйозність і пріоритет дефекту. Життєвий цикл дефекту.

  1. qalearning
    Червень 9, 2015 at 11:56

    Зміст:

    1. Введення в тестування програмного забезпечення
    2. Особливості вимог програмного забезпечення. Методи тестування. Фази тестування. Класи еквівалентності.
    3. Види Тест Кейсiв. Стани Тест Кейсiв. Багтрекінгові системи. Серйозність і пріоритет дефекту. Життєвий цикл дефекту.
    4. Рівні тестування
    5. Види тестування ПО. Функціональне тестування (Functional Testing). Тестування безпеки (Security and Access Control Testing). Тестування взаємодії (Interoperability Testing)
    6. Нефункціональне тестування ПЗ
    7. Види тестування, пов’язані зі змінами. Кросбраузерність.
    8. Agile (Гнучка модель). Scrum. Selenium

Comments are closed.