Кроки для підтримки хорошої бази даних про помилки

Підтримка бази помилок є важливим для кожного проекту. Я звик зберігати наступні дані в базі даних про помилки

• Час дати випуску
• Кому призначено
• Чи вирішено воно чи ні
• Якщо тоді вирішено, вирішується час дати

Чи достатньо їх для підтримки гарної бази помилок?

Хороша база помилок може мати наступні підписки

// Дата, пов’язана з часом

• Час видачі помилки
• Очікуваний час виправлення / вирішення дати
• Якщо тоді вирішено, вирішується час дати

// Призначається за + До

• Призначається (виявлено)
• Присвоєно

// Поведінка помилок

• Спостерігається (баггі) поведінка
• Знімок екрана (можливо)
• Виконайте кроки для відтворення помилки
• Очікувана поведінка

// Пріоритет

• Пріоритет помилки

// Посилання, статус та інші

• Посилання пов’язаних помилок
• Статус помилки
• Чи вирішено воно чи ні
• Якщо вирішити тоді, як вирішено з поясненням

EDIT: Я також хочу рекомендувати

• У якій редакції / відділенні виявлено помилку
• У якій редакції / гілки виправлено помилку

EDIT: Мені подобається коментар @ jgauffin

• Не вдалося виправити, не помилка, дублікат, вирішено

EDIT: Хороша система баз даних про помилки також підтримується

• Матриця присвоєння відповідальності

Можливо, існує декілька спеціальних полів, які вам можуть знадобитися ввійти, залежно від потреб проекту. Я придумав такий перелік, який, можливо, вам доведеться також врахувати:

• Випуск DateTimeпомилки / дефекту
• Опис помилки - кроки для відновлення.
• Середовище, де його знайшли (Dev, QA, QC, Staging, Prod)
• Знімок екрана
• Хто ввійшов у нього (виявлено)
• Кому призначено (призначено)
• Тяжкість помилки (низький, середній, високий)
• Очікувана резолюція DateTime
• Державна угода (запропоновано, не завершено, вирішено, закрито)
• Помилка закрита DateTime- коли помилка вирішена та закрита
• Призначений для тестування (випробування)

Редагувати: Більшість поширених відомостей, які мають значення для відстеження, добре описані в програмному забезпеченні, як Bugzilla . Bugzilla - це веб-баггічний інструмент загального призначення та тестування, спочатку розроблений та використовуваний проектом Mozilla, а також ліцензований під публічною ліцензією Mozilla - і БЕЗКОШТОВНО . Я б настійно радив взяти їх як основний приклад та продовжити його на потреби вашого проекту.

Здається, більшість корисних полів вже охоплені іншими відповідями, але деякі, які я вважаю корисними, це:

• У якій редакції / відділенні виявлено помилку.
• У якій редакції / галузі було зафіксовано

Це дещо конкретніше, ніж на дату / час, коли помилка була виявлена ​​/ виправлена.

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

Але для підтримки бази даних про помилку є більше, ніж поля, які вона повинна містити. Вам також потрібно врахувати, як ви використовуєте базу.

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

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

• Дата відкриття
• Відкрив
• Дата вирішення
• Розв’язано
• Витрачений час
• Як було вирішено
• тощо.

Також вам може знадобитися подібна таблиця, щоб відстежити, кому і коли помилка була (пере) призначена, особливо якщо ви працюєте у великій команді.

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

Процес відстеження помилок так само важливий, як і дані. Спробуйте також подумати над наступним:

• Як користувачі повідомляють про помилку?
• Хто вводить помилку в сховище?
• Хто може підтвердити наявність помилки?
• Хто може підтвердити, що помилка вирішена?
• Хто інформує кінцевого користувача про те, що помилка вирішена?

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