Основні поля баг/дефект репорту

Основні поля баг/дефект репорту

Різні системи управління дефектами, пропонують нам різні поля для заповнення та різні структури опису дефектів. Нижченаведена таблиця - це спроба показати те, що на основі отриманого нами досвіду ми рекомендуємо вам використовувати у вигляді шаблону баг репорту .

Шапка
Короткий опис (Summary)	Короткий опис проблеми, що явно вказує на причину і тип помилкової ситуації.
Проект (Project)	Назва тестованого проекту
Компонент програми (Component)	Назва частини або функції продукту, що тестується
Номер версії (Version)	Версія на якій було знайдено помилку
Серйозність (Severity)	Найбільш поширена п'ятирівнева система градації серйозності дефекту: S1 Блокуючий (Blocker) S2 Критичний (Critical) S3 Значний (Major) S4 Незначний (Minor) S5 Тривіальний (Trivial) (Докладніше дивіться нижче в розділі Серйозність дефекту)
Пріоритет (Priority)	Пріоритет дефекту: P1 Високий (High) P2 Середній (Medium) P3 Низький (Low) (Докладніше дивіться нижче у розділі Пріоритет дефекту)
Статус (Status)	Статус бага. Залежить від процедури та життєвого циклу бага (bug workflow and life cycle)
Автор (Author)	Творець баг репорту
Призначений на (Assigned To)	Ім'я співробітника, призначеного на вирішення проблеми
Оточення
ОС/Сервіс Пак і т.д. / Браузера + версія / ...	Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, для WEB тестування - ім'я та версія браузера тощо.
...
Опис
Кроки відтворення (Steps to Reproduce)	Кроки, якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result)	Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result)	Очікуваний правильний результат
Доповнення
Прикріплений файл (Attachment)	Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми