6. Дата складання.

Ця інформація може знадобитися як на "розборі польотів", так і при подальшій роботі з даною проблемою. Зазвичай вноситься автоматично при створенні нового звіту.

В паперовій версії - заповнюється відповідний пункт звіту.

В електронній - вноситься автоматично.

Вноситься - автоматично при складанні звіту тестувальником.

Модифікується - найчастіше не модифікується або модифікується тим, хто вніс або уповноваженою особою (керівником або менеджером).

7. Дата останньої модифікації.

Для щойно внесеного звіту дата в цьому полі буде збігатися з датою складання, але при роботі з багом, описаним раніше, дана дата буде говорити про те, коли в останній раз вносилися зміни в опис даної проблеми або в коментар до неї. Формат обох дат, як правило, індивідуальний і залежить від сервера, на якому розташована система трекінгу. Важливо, щоб він (формат) для всіх дат був однаковий.

В паперовій версії - заповнюється відповідний пункт звіту.

В електронній - вноситься автоматично.

Вноситься - автоматично при складанні звіту тестувальником.

Модифікується - найчастіше не модифікується або модифікується тим, хто вніс або уповноваженою особою (керівником або менеджером).

8. Серйозність проблеми (Severity).

Даний пункт дозволяє класифікувати баги по їх серйозності, тобто на скільки сильно дана проблема "шкодить" функціональності. Перелік Severity і їх кількість може варіюватися в різних компаніях. Найбільш вживаними можуть бути наступні:

1. Fatal (Critical, Causing crash) - проблеми, що призводять до зависання і / або руйнування системи, втрати даних, які не мають workaround і т.д.

2. Serious - помилки у функціональності мають workaround.

3. Minor (Cosmetic) - дрібні помилки не заважають роботі програми.

4. Suggestion (Enhancement) - пропозиція щодо поліпшення (наприклад, інтрефейса).

5. Question (Питання) - звіт про проблему, якщо існує сумнів у тому, чи є описувана ситуація багом (наприклад, в документації не описано поведінку програми в даній ситуації і тестувальник сумнівається, чи є отриманий в ході тестування результат правильним).

Крім того, Severity можуть взагалі не мати назви, а бути просто пронумеровані.

Останні два значення (Suggestion і Question) можуть входити до складу графи Тип звіту, якщо така є в використовуваної системі трекінгу

В паперовій версії - заповнюється відповідний пункт звіту.

В електронній - вибирається із списку.

Вноситься - тестувальником.

Модифікується - найчастіше не модифікується або модифікується тим, хто вніс або уповноваженою особою (керівником або менеджером).

9. Пріоритет (Priority).

Даний параметр визначає, в якій послідовності знайдені проблеми будуть виправлятися програмістом. В першу чергу виправляються проблеми з більш високим пріоритетом. Так само як і у випадку з серйозністю проблеми назви пріоритетів і їх кількість можуть відрізнятися в різних компаніях і системах трекінгу або вони можуть взагалі не мати назви, а бути просто пронумеровані. При цьому найвищий пріоритет, як правило, буде мати найменший номер. Найчастіше використовуються 4 пріоритети:

1. Дуже високий (very high) - помилки з цим пріоритетом виправляються в першу чергу.

2. Високий (high) - виправляються після того, як ліквідовані всі помилки very high.

3. Низький (low) - проблеми з таким пріоритетом "чиняться" по мірі можливості.

4. Дуже низький (very low) - виправлення цих помилок може бути відкладене на невизначений термін, якщо залишиться на них час.

або 3:

1. Високий - виправлення виробляються негайно після виявлення.

2. Середній - виправлення можуть бути відкладені до наступної версії.

3. Низький - виправлення будуть зроблені в останню чергу або можуть бути відкладені на невизначений термін.

В паперовій версії - заповнюється відповідний пункт звіту.

В електронній - вибирається із списку.

Вноситься - тільки керівником проекту або менеджером.

Модифікується - керівником проекту або менеджером.