Kroki prowadzące do utrzymania dobrej bazy danych błędów

Utrzymanie bazy danych błędów jest ważne dla każdego projektu. Jestem przyzwyczajony do przechowywania następujących danych w bazie danych błędów

• Data wydania czas
• Kto jest przypisany
• Czy zostało to rozwiązane czy nie
• Jeśli rozwiązane, rozwiązana data i godzina

Czy to wystarczy, aby utrzymać dobrą bazę błędów?

Dobra baza danych błędów może zawierać następujące elementy

// Data i czas

• Data wydania godzina błędu
• Oczekiwana data rozwiązania / rozwiązania
• Jeśli rozwiązane, rozwiązana data i godzina

// Przypisany przez + Do

• Przypisany przez (wykryty przez)
• Przypisane do

// Zachowanie błędów

• Obserwowane (błędne) zachowanie
• Zrzut ekranu (jest możliwy)
• Wykonaj kroki, aby odtworzyć błąd
• Spodziewane zachowanie

// Priorytet

• Priorytet błędu

// Link, Status i inne

• Link do powiązanych błędów
• Status błędu
• Czy zostało to rozwiązane czy nie
• Jeśli tak, to jak rozwiązać z wyjaśnieniem

EDYCJA: Chcę również polecić

• W jakiej wersji / gałęzi wykryto błąd
• W jakiej wersji / gałęzi naprawiono błąd

EDYCJA: Podoba mi się komentarz @ jgauffin

• Nie naprawi, to nie błąd, duplikat, rozwiązany

EDYCJA: Utrzymuje się także dobry system bazy danych błędów

• Macierz przydziału odpowiedzialności

W zależności od potrzeb projektu może być konieczne zarejestrowanie wielu niestandardowych pól . Wymyśliłem następującą listę, którą możesz również rozważyć:

• Problem DateTimez błędem / usterką
• Opis błędu - kroki do odtworzenia.
• Środowisko, w którym się znalazło (Dev, QA, QC, Staging, Prod)
• Zrzut ekranu przedstawiający problem
• Kto to zalogował (wykryty przez)
• Do kogo jest przypisany (przypisany przez)
• Poziom ważności błędu (niski, średni, wysoki)
• Oczekiwana rozdzielczość DateTime
• Triage stanu (proponowane, w toku, rozwiązane, zamknięte)
• Bug is Closed DateTime- kiedy błąd zostanie rozwiązany i zamknięty
• Przypisany do testowania (testowany przez)

Edycja: Większość typowych informacji, które mają być śledzone, jest dobrze opisana w oprogramowaniu takim jak Bugzilla . Bugzilla to internetowy uniwersalny narzędzie do śledzenia błędów i testowania, pierwotnie opracowane i używane przez projekt Mozilla, licencjonowane na licencji publicznej Mozilla - i jest BEZPŁATNE . Chciałbym mocno rada wziąć je jako podstawowy przykład i przedłużyć go od potrzeb projektu.

Wygląda na to, że większość przydatnych pól została już uwzględniona w innych odpowiedziach, ale niektóre, które uważam za przydatne, to:

• W jakiej wersji / gałęzi wykryto błąd.
• W jakiej wersji / gałęzi została naprawiona.

Jest to nieco bardziej szczegółowe niż data / godzina wykrycia / usunięcia błędu.

Jeśli twoje oprogramowanie działa na kilku platformach (system operacyjny lub sprzęt), możesz także chcieć mieć pole z listą platform, na których występuje błąd.

Baza danych błędów zawiera jednak coś więcej niż tylko pola, które powinna ona zawierać. Musisz także rozważyć sposób korzystania z bazy.

Staraj się, aby liczba otwartych / nierozwiązanych błędów była jak najniższa. Może się to wydawać oczywiste, ale może być trudniejsze niż oczekiwano, przynajmniej w przypadku większych projektów. Często widzę ludzi zbyt obawiających się, aby zamknąć problemy, które są albo niemożliwe do odtworzenia, albo w których brak informacji nigdy nie jest dostarczany przez pierwotnego autora problemu. Nie należy również pozostawiać błędów, które od zawsze były obecne i były ostatnio widziane w starożytnych wersjach oprogramowania. To sprawia, że ​​baza danych rośnie z problemami, które mogą, ale nie muszą być prawdziwymi problemami, i spowalnia rozwój.

Często trzeba zobaczyć historię błędu - może zostać rozwiązany, a następnie ponownie otwarty, a następnie rozwiązany ponownie itd. Tak więc oprócz tego, co zostało już zasugerowane, radzę mieć osobną tabelę do śledzenia historii błędu za każdym razem, gdy jest (ponownie) otwierany. Tabela byłaby w relacji wiele do jednego z tabelą błędów i prawdopodobnie zawierałaby pola takie jak:

• Data otwarcia
• Otwarty przez
• Data rozwiązania
• Rozwiązane przez
• Czas spędzony
• Jak zostało rozwiązane
• itp.

Możesz także potrzebować podobnej tabeli, aby śledzić, komu i kiedy błąd został (ponownie) przypisany, szczególnie jeśli pracujesz w dużym zespole.

Sugeruję również przyjrzenie się istniejącym systemom. IMHO Jira to jeden z najlepszych systemów śledzenia problemów. Ma bardzo bogate funkcje i możesz użyć niektórych z nich jako przewodnika dla własnego systemu.

Proces śledzenia błędów jest tak samo ważny jak dane. Spróbuj również pomyśleć o następujących kwestiach:

• Jak użytkownicy zgłaszają błąd?
• Kto wprowadza błąd do repozytorium?
• Kto może potwierdzić, że błąd istnieje?
• Kto może potwierdzić, że błąd został rozwiązany?
• Kto informuje użytkownika końcowego, że błąd został rozwiązany?

Zbuduj tabelę RACI, aby wszyscy w zespole (w tym użytkownicy końcowi znali swoje obowiązki. Połącz to z odpowiednimi technikami wprowadzania danych, a zobaczysz o wiele więcej wartości przy niewielkim dodatkowym wysiłku.