2. Номер версії програми, що тестується.

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

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

Вноситься в першу чергу самим тестувальником, а в більшості випадків - тільки їм.

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

3. Номер збірки програми.

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

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

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

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

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

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

4. Функціональна область.

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

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

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

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

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

5. Піб особи що склав звіт.

Тут вказується прізвище та ініціали того, хто виявив і повідомив про проблему.

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

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

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

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

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