Definicja

Bug (błąd, defekt) to rozbieżność między faktycznym działaniem oprogramowania a jego specyfikacją lub oczekiwaniami użytkownika. Błędy mogą wynikać z pomyłek w kodzie, błędnej logiki biznesowej, niejasnych wymagań lub problemów z infrastrukturą. W inżynierii oprogramowania proces identyfikacji, dokumentowania i naprawy błędów jest kluczowy dla utrzymania wysokiej jakości Inkrementu.

Cykl życia błędu (Bug Life Cycle)

W profesjonalnych zespołach błąd przechodzi przez kilka standardowych etapów, zarządzanych zazwyczaj w systemach takich jak Jira czy Azure DevOps:

  1. New (Nowy): Błąd został zgłoszony, ale jeszcze nie zweryfikowany.
  2. Assigned (Przypisany): Programista bierze odpowiedzialność za naprawę.
  3. In Progress (W trakcie): Trwają prace nad poprawką kodu.
  4. Fixed / Ready for QA (Naprawiony): Kod został zmieniony, błąd czeka na ponowne przetestowanie.
  5. Verified (Zweryfikowany): Tester potwierdza, że błąd już nie występuje.
  6. Closed (Zamknięty): Proces naprawy zakończony sukcesem.

Jak poprawnie zgłosić błąd?

Dobre zgłoszenie błędu pozwala deweloperowi na szybką diagnozę bez zbędnych pytań. Powinno zawierać:

  • Tytuł: Krótki i konkretny (np. “Błąd 500 przy próbie zapisu pustego koszyka”).
  • Kroki do reprodukcji: Dokładna lista czynności prowadząca do błędu.
  • Rezultat oczekiwany vs Rzeczywisty: Co powinno się stać, a co się stało.
  • Środowisko: Informacja o przeglądarce, wersji systemu czy urządzeniu.
  • Załączniki: Zrzuty ekranu, nagrania wideo lub logi systemowe.

Klasyfikacja błędów (Priorytet vs Surowość)

Podczas analizy systemowej błędy kategoryzuje się według dwóch parametrów:

Parametr Opis Skala
Severity (Surowość) Jak bardzo błąd wpływa na działanie systemu od strony technicznej. Critical, Major, Minor, Trivial.
Priority (Priorytet) Jak szybko błąd musi zostać naprawiony z punktu widzenia biznesu. High, Medium, Low.

Przykład: Literówka w logo na stronie głównej ma niską surowość (system działa), ale wysoki priorytet (wizerunek firmy cierpi). Z kolei błąd w rzadko używanym raporcie technicznym może mieć wysoką surowość, ale niski priorytet.

Bug a Wymagania (Change Request)

Częstym wyzwaniem dla analityka biznesowego jest rozstrzygnięcie: czy to bug, czy nowe wymaganie?

  • Jeśli system działa zgodnie z opisanymi wcześniej Kryteriami Akceptacji, ale użytkownik chce, aby działał inaczej – jest to Change Request (nowe wymaganie).
  • Jeśli system działa niezgodnie z dokumentacją lub powoduje błędy techniczne – jest to Bug.

Typowe błędy w zarządzaniu bugami

  • ❌ Brak wystarczających informacji – Zgłoszenie typu “nie działa”, które uniemożliwia reprodukcję.
  • ❌ Kumulowanie błędów (Bug Backlog) – Pozwalanie, by liczba drobnych błędów rosła w nieskończoność, co zwiększa Dług Techniczny.
  • ❌ Naprawianie skutków, nie przyczyn – “Łatanie” objawów bez analizy systemowej, dlaczego błąd w ogóle wystąpił.

Podsumowanie

Zarządzanie błędami to nie tylko praca testerów, ale proces wymagający zaangażowania całego zespołu. Dla Product Ownera zrozumienie stanu “zdrowia” produktu wyrażonego w liczbie otwartych bugów jest niezbędne do podjęcia decyzji o kolejnym wydaniu na produkcję.

Powiązane pojęcia:

Kliknij w pojęcie, aby przejść do jego definicji w słowniku