Odpowiedź.

Cykl życia błędu to proces, przez który przechodzi każdy znaleziony defekt: od jego wykrycia do zamknięcia. W IT cykl życia błędu sformalizował się w celu przyspieszenia przetwarzania defektów, minimalizacji ryzyk i przejrzystości w prowadzeniu prac.

Historia pytania:

Wczesne systemy śledzenia błędów pozwalały tylko na rejestrowanie błędów. W miarę skomplikowania oprogramowania pojawiło się zapotrzebowanie na strukturalne śledzenie statusów błędów oraz opis wszystkich etapów ich przetwarzania.

Problem:

Bez formalnych etapów defekty mogą się gubić, "zawieszać", pozostawać otwarte, nawet jeśli zostały usunięte. Możliwe są także nieporozumienia między QA a programistami z powodu braku przejrzystości w kwestii tego, kto i co powinien robić.

Rozwiązanie:

Standaryzacja etapów (np. Nowy, Otwarty, Przydzielony, W trakcie, Naprawiony, Do testów, Zamknięty, Ponownie otwarty) oraz opis działań na każdym etapie pomagają uporządkować proces przetwarzania defektów i uczynić go przejrzystym.

Kluczowe cechy:

Standardowe przejścia między etapami
Współpraca różnych ról (QA, Dev, Lead)
Elastyczność w ustawieniach konkretnego narzędzia śledzącego (Jira, Redmine itd.)

Pytania z podstępem.

Czy można zamknąć błąd, jeśli został odtworzony u testera, ale nie u programisty?

Nie, błąd musi być zatwierdzony przez obie strony i być odtwarzany według zapisanych kroków w raporcie błędu.

Co zrobić, jeśli przyszła odpowiedź na błąd 'Nie naprawimy'?

QA powinien wyjaśnić przyczynę odmowy. Jeśli przyczyna jest uzasadniona (niska krytyczność, zgodność z wymaganiami), błąd można zamknąć z komentarzem.

Czy QA musi ponownie utworzyć błąd, jeśli po jego zamknięciu problem pojawił się ponownie?

Nie, należy przełączyć błąd na status „Ponownie otwarty” i dodać nowe szczegóły dotyczące odtwarzania.

Typowe błędy i antywzorce

Zamykanie błędów bez weryfikacji poprawki (testu regresyjnego)
Zbyt wiele statusów utrudniających pracę zespołu
Ignorowanie komunikacji przy zmianie statusów

Przykład z życia

Negatywny przypadek

W firmie wykorzystywano tylko podstawową funkcjonalność dziennika błędów. Po usunięciu defektu programista oznaczał go jako rozwiązany, tester nie przeprowadzał ponownego testowania, błędy trafiały do wydania.

Plusy:

Szybki feedback między QA a Dev.

Minusy:

Wiele nie naprawionych błędów.
Regresje trafiają do wydania.

Pozytywny przypadek

Zespół wdrożył standardowy cykl życia błędu z obowiązkowym testem regresyjnym i opisem przyczyn zamknięcia przed wydaniem.