Jak klasyfikować błędy dla programisty?

Klasyfikacja błędów pomaga programistom szybciej zrozumieć problem i określić priorytet naprawy. Główne kryteria klasyfikacji:

• Poważność (Severity): Wpływ błędu na działanie aplikacji.
  • Blokujący: Aplikacja jest całkowicie nieczynna lub kluczowa funkcja jest niedostępna, brak obejść.
  • Krytyczny: Poważne naruszenie funkcjonalności, wpływające na znaczną liczbę użytkowników lub kluczowe procesy biznesowe. Mogą istnieć częściowe obejścia lub tymczasowe rozwiązania.
  • Główny: Znaczące naruszenie funkcjonalności lub użyteczności, ale bez pełnego blokowania.
  • Drobny: Nieznaczne naruszenie funkcjonalności, defekty kosmetyczne, błędy ortograficzne. Nie wpływa istotnie na działanie aplikacji.
  • Błahy: Drobne defekty, prawie nie wpływające na użytkowanie, mogą być naprawione jako ostatnie.
• Priorytet (Priority): Pilność naprawy błędu. Ustalany wspólnie przez QA i Product Owner/Team Lead.
  • Najwyższy: Wymaga natychmiastowej naprawy, blokuje wydanie wersji lub krytycznie wpływa na kluczowych użytkowników.
  • Wysoki: Powinien być naprawiony w najbliższym czasie, wpływa na ważne scenariusze użytkowania.
  • Średni: Zaleca się naprawę przed następną wersją.
  • Niski: Może być naprawiony w kolejnych wersjach, nie jest krytyczny.
• Typ (Type): Kategoria defektu.
  • Funkcjonalny: Błąd w działaniu funkcji.
  • UI/UX: Problemy z wyglądem lub użytecznością.
  • Wydajność: Problemy z wydajnością (czas ładowania, responsywność).
  • Bezpieczeństwo: Luki bezpieczeństwa.
  • Kompatybilność: Błędy związane z działaniem na różnych urządzeniach, przeglądarkach, systemach operacyjnych.
  • Integracja: Problemy z interakcją między modułami lub systemami.
  • Użyteczność: Trudności w korzystaniu z interfejsu lub wykonywaniu zadań.
• Status: Aktualny stan błędu w cyklu życia.
  • Nowy: Utworzony niedawno.
  • Otwarte: Przyjęte do pracy.
  • W trakcie: Nad nim pracują.
  • Naprawione: Naprawione przez programistę.
  • Oczekuje na retest: Czeka na retest QA.
  • Ponowne otwarcie: Nie przeszedł retestu, ponownie przypisany do programisty.
  • Zamknięte: Pomyślnie przeszedł retest.
  • Odrzucone / Nie można odtworzyć: Błąd nie jest odtwarzalny lub nie jest defektem.
  • Odkładane: Naprawa odłożona na późniejszy termin.

Podczas dostarczania informacji ważne jest również zawarcie jasnego opisu kroków reprodukcji, aktualnego i oczekiwanego wyniku, wersji build/środowiska oraz logów.