22. Резолюція (Resolution).

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

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

В електронній - являє собою текстове поле для введення інформації з можливістю автоматичного внесення дати, часу та ПІБ особи, що вносить коментар.

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

23. Відкладено (Deffered).

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

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

В електронній - являє собою текстове поле для введення інформації з можливістю автоматичного внесення дати, часу та ПІБ особи, відкласти виправлення.

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

24. Підпис (нотифікація для електронного варіанту) (Signature / Notify).

В паперовій версії - підпис особи що склав звіт.

Являє собою запис про відправку нотифікації (повідомлення) із зазначенням часу, дати та ПІБ одержувача.

В паперовій версії - графа, заповнювана упорядником звіту.

В електронній - поле з описаною інформацією.

Вноситься і модифікується в паперовому варіанті - укладачем звіту, а в електронному - системою трекінгу (автоматично).

25. Історія (History).

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

В паперовій версії - відсутня.

В електронній - поле з описаною інформацією.

Вноситься і модифікується в електронному варіанті - системою трекінгу (автоматично).

Системи відстеження багів

Система відслідковування помилок (англ. bug tracking system) - це прикладна програма, яка призначається для допомоги у веденні обліку і контролю помилок (багів), знаходження їх в програмах, а також слідкування за процесом усунення цих помилок.

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

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

Життєвий цикл дефекту

Кожен дефект має свій життєвий цикл.

Типовий життєвий цикл дефекту:

1. Новий - дефект зареєстрований тестувальником

2. Призначений - призначений відповідальний за виправлення дефекту

3. Дозволений - дефект переходить назад в сферу відповідальності тестувальника. Як правило, супроводжується резолюцією, наприклад:

   1. Виправлено (виправлення включені у версію таку-то)

   2. Дубль (повторює дефект, який вже знаходиться в роботі)

   3. Не виправлено (працює у відповідності зі специфікацією, має занадто низький пріоритет, виправлення відкладено до наступної версії і т.п.)

   4. «У мене все працює» (запит додаткової інформації про умови, в яких дефект проявляється)

4. Далі тестувальник проводить перевірку виправлення, в залежності від чого дефект або знову переходить у статус Призначено (якщо він описаний як виправлений, але не виправлений), або в статус Закрито.

5. Відкрито повторно - дефект знову знайдений в іншій версії.

Система може надавати адміністратору можливість налаштувати, які користувачі можуть переглядати і редагувати помилки в залежності від їх стану, переводити їх в інший стан або видаляти.

Приклади систем відслідковування помилок.

Такі, що вільно поширюються

• Redmine

• BUGS - the Bug Genie

• Bugzilla

• eTraxis

• GNATS

• Mantis bug tracking system

• Trac

• EmForge

• Picket

• Flyspray

• DEVPROM

• YouTrack

Пропрієтарні

• Atlassian JIRA

• Bontq

• PVCS Tracker

• Project Kaiser

• TrackStudio Enterprise

Різні

• BugTracker.NET

• ClearQuest

• Intland CodeBeamer

• LifeTask.ru

• FlySpray

• StarTeam