10. Статус (стан) (Status).

Статус дозволяє визначити, на якій стадії свого життєвого циклу перебуває баг. Іншими словами статус характеризує, на якій стадії зараз перебуває робота над багом. Крім того, в електронних системах трекінгу дане поле може використовуватися для складання фільтрів, за допомогою яких користувачі системи вестимуть пошук багів в залежності від їх ролі в проекті. Наприклад, програміст буде вести пошук по статусах Новий (New (Open)) і Переробити (Re-do (Re-open)), а тестер - за статусом Виправлено (Fixed (Added)) і т.д.

Так само як і Severity і Priority назви статусів можуть варіюватися від компанії до компанії.

1. Новий (New (Open)) - статус, який присвоюється щойно складеним звітом про проблему.

2. У роботі (In process) - статус, який свідчить про те, що в даний момент іде робота по виправленню (або прийняттю іншого рішення).

3. Виправлено (Fixed (Added)) - описана помилка виправлена, необхідна перевірка виправлення.

4. Переробити (Re-do (Re-open)) - в ході перевірки виправлення баг виявлений повторно.

5. Закрито (Closed (Verified)) - описана помилка перевірена, виправлення дійсно має місце, подальша робота над описаним в рапорті багом зупинена.

6. Відкладено (Deffered) - виправлення відкладено на невизначений термін.

До питання про ведення бази.

Сем Канер зі співавторами в згаданій вище книзі рекомендують дещо інші стани:

1. Відкрито - статус щойно написаного звіту.

2. Вирішено - прийнято рішення з проблеми, результат описаний в графі Резолюція.

3. Зачинено - виставляється після виправлення помилки або прийняття рішення, яке не потребує подальшої роботи зі звітом.

При цьому автор пише: "У деяких компаніях використовують три варіанти стану питання: відкриті, закриті та Вирішено. Програмісти шукають в базі даних звіти за станом Відкрито, а тестувальники за станом Вирішено

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

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

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

Модифікується - тестувальником (New, Re-do (Re-open), Closed (Verified)); програмістом (У роботі (In process), Виправлено (Fixed (Added))); керівником проекту або менеджером (в залежності від ролі в проекті список доступних статусів може розрізнятися. Наприклад, тестировщик не може виставляти статус "виправлено", а програміст - виставляти статус "закрито").

11. Тип звіту (Problem type).

В цій графі вказують тип виявленої проблеми.

Сем Канер з співавторами пропонують такі типи звіту для використання в системах трекінгу:

1. Відкрито - статус тільки що написаного звіту.

2. Вирішено - прийнято рішення з проблеми, результат якого описаний в графі Резолюція.

3. Зачинено - виставляється після виправлення помилки або прийняття рішення, яке не потребує подальшої роботи зі звітом.

При цьому автор пише: "У деяких компаніях використовують три варіанти стану питання: відкриті, закриті та Вирішено. Програмісти шукають в базі даних звіти за станом Відкрито, а тестувальники за станом Вирішено. У нашій системі програмісти шукають звіти по резолюції Розглядається, а тестувальники по Станом Відкрито з будь-якими резолюціями, крім Розглядається. "

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

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

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

Модифікується - тестувальником (New, Re-do (Re-open), Closed (Verified)); програмістом (У роботі (In process), Виправлено (Fixed (Added))); керівником проекту або менеджером (в залежності від ролі в проекті список доступних статусів може розрізнятися. Наприклад, тестировщик не може виставляти статус "виправлено", а програміст - виставляти статус "закрито").

Сем Канер з співавторами пропонують такі типи звіту для використання в системах трекінгу:

"1. Помилка кодування. Програма поводить себе не так, як повинна себе поводити, на думку тестувальника. Наприклад, якщо програма стверджує, що 2 +2 = 3, то це явна помилка кодування. Програміст ж у відповідь на звіт про таку помилку цілком може написати Відповідає проекту.

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

3. Пропозиція. Звіт такого типу не означає, що в програмі щось не так. У ньому описується ідея, реалізація якої, на думку тестувальника, може поліпшити програму.

4. Розбіжність з документацією. Програма поводить себе не так, як описано в керівництві або електронній довідці. У цьому випадку в звіті слід вказати, в якому саме документі і на якій сторінці знайдено невідповідність. При цьому в звіті зовсім не стверджується, що помилка саме в документації, а не в самій програмі. Звіти про розбіжність з документацією обов'язково повинні спільно розглядатися програмістом і автором документації. Про функції програми, які взагалі ніде не описані, так само слід складати звіти даного типу.

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

6. Питання. Програма робить щось, чого тестувальник не очікує або не розуміє. Звіт-питання варто скласти при будь-яких сумнівах. Якщо вони виявляться заснованими на реальній помилці, програміст її виправить. Якщо ж програміст відмовиться виправити помилку або його пояснення не здасться вам досить розумним, можна буде скласти звіт про помилку проектування ".

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

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

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