12. Повторюваність (Recurrence).

Дана графа звіту є відповіддю на запитання "Чи можете Ви відтворити проблему?" Тобто Чи стабільно при проведенні даного тесту проявляється описувана помилка. Варіантами відповіді можуть бути (по Канеру):

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

2. Ні - баг виник одноразово і тестувальнику не вдається отримати цю помилку ще раз. Тобто не відомо як її відтворити.

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

При складанні звіту не відтворювані помилки слід вносити в базу з особливою ретельністю.

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

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

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

13. Ідентифікатор (Identifier).

Унікальний ідентифікатор повідомлення про помилку. Може використовуватися тільки один раз в системі. Як правило, в ідентифікаторі часто використовують поєднання букв і цифр, де букви - абревіатура назви тестованої програми, а цифри - унікальний номер бага (звіту про проблему).

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

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

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

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

14. Короткий опис (Description).

Стислий опис суті проблеми. Це опис використовується для ідентифікації бага в базі даних (як і його ID), а також в різного виду звітах і рапортах про виконану роботу. Більш докладний опис і вказівки, як відтворити проблему, описуються в інших графах звіту. Коротке формулювання є дуже важливим, тому що по ньому можуть судити про важливість проблеми. Крім того, навіть у разі схожих проблем, для яких складаються окремі звіти - Description повинен бути різний.

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

В електронній - являє собою текстове поле для введення інформації.

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

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

15. Детальний опис (Report).

Детальний опис проблеми. Чим докладніше буде описано, в чому саме полягає проблема, тим легше локалізувати і виправити баг. Проте надмірна інформація може також ускладнити розуміння, як і її нестача. У частині систем трекінгу дане поле використовується і для опису кроків відтворення, і для вказівки наявності обхідного шляху, і для опису апаратної / програмної конфігурації, в якій дана проблема виникає.

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

В електронній - являє собою текстове поле для введення інформації.

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

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

16. Кроки відтворення (Step to recreate).

У цій графі докладно, по кроках описується, що саме потрібно робити, щоб відтворити проблему. Це поле є дуже важливим, тому що при його написанні тестувальник має можливість перш за все для себе усвідомити чи стабільно виникає помилка, а програміст зможе відтворити проблему у себе, що в свою чергу може істотно полегшити локалізацію, отже і виправлення знайденої помилки. Крім того це поле знадобиться Тестувальнику і надалі - для повторної перевірки зробленого виправлення.

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

В електронній - являє собою текстове поле для введення інформації.

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

Модифікується - тестувальником. Для подальших записів може використовуватися поле Коментар (див. нижче).