Co się dzieje z raportem o błędzie, jeśli nie został naprawiony?

Jeśli zgłoszenie błędu nie zostało naprawione, przechodzi przez następujące etapy w cyklu życia:

• Otwarte (Open): Zgłoszenie błędu jest tworzone i przekazywane zespołowi deweloperskiemu.
• Przypisane (Assigned): Zadanie naprawy błędu jest przypisywane konkretnemu deweloperowi lub zespołowi.
• Odrzucone (Rejected / Declined): Błąd może zostać odrzucony z różnych powodów:
  • Nie jest błędem (Not a Bug): Opisane zachowanie jest oczekiwanym funkcjonowaniem.
  • Duplikat (Duplicate): Błąd został już wcześniej zarejestrowany.
  • Nie można odtworzyć (Cannot Reproduce): Nie można odtworzyć błędu na podstawie podanych kroków.
  • Nie zostanie naprawiony (Will Not Fix): Błąd nie zostanie naprawiony zgodnie z decyzją kierownictwa (niski priorytet, wysokie ryzyko naprawy, brak zasobów itp.).
  • Potrzebne więcej informacji (Need More Info): Wymagane są dodatkowe informacje do odtworzenia lub zrozumienia problemu.
• Odłożone (Deferred / Postponed): Naprawa błędu została odłożona na późniejszą wersję lub iterację z powodu wyższych priorytetów lub braku czasu/zasobów.
• Zamknięte (Closed): W przypadku odrzucenia lub odłożenia, zgłoszenie błędu ostatecznie przechodzi do statusu "Zamknięte", ale bez naprawy.

Ostateczny los nie naprawionego błędu zależy od jego statusu i podjętej decyzji:

• Jeśli odrzucony, zgłoszenie błędu jest po prostu archiwizowane. Mogą być dodane odpowiednie komentarze z uzasadnieniem.
• Jeśli odłożony, może zostać ponownie otwarty w przyszłości, gdy pojawi się możliwość jego naprawy, lub ostatecznie zamknięty, jeśli decyzja o nie naprawianiu stanie się ostateczna.

Ważne jest, aby w systemie zarządzania błędami istniała jasna historia zmian statusów i komentarzy wyjaśniających przyczyny każdego przejścia.