Cykl życia błędu

W poprzednim rozdziale zapoznaliśmy się z definicją błędu. Rozpatrzyliśmy podejście potoczne oraz interpretację ISTQB.

Testując system, po znalezieniu błędu, powinniśmy go zgłosić za pomocą odpowiedniego dla projektu narzędzia. Jednak rola testera nie kończy się tylko na zgłoszeniu błędu. Błąd posiada swój cykl życia, a tester powinien być odpowiedzialny za zgłoszony przez siebie błąd i nadzorować jego przepływ.

Czym jest cykl życia błędu?

Cykl życia błędu to proces, któremu poddawany jest błąd od etapu jego zgłoszenia, aż po jego zamknięcie. Rozpoczyna się w momencie wykrycia przez testera błędu, usterki, trwa w trakcie naprawy i retestów, a kończy w chwili rozwiązania problemu. W zależności od wykorzystywanego narzędzia i metodyki wytwarzania oprogramowania, przepływy mogą mieć różny wygląd. W dalszej części artykułu przedstawię przykładowy podstawowy przepływ, który może być wykorzystywany w tworzeniu projektów informatycznych (por. wykres poniżej).

Jakie stany cyklu życia błędu wyróżniamy?

Wyróżniamy następujące stany cyklu życia błędu (w zależności od narzędzia ich nazwa może się delikatnie różnić):

• NEW – NOWY – błąd został znaleziony przez testera i zgłoszony do odpowiedniego narzędzia. Błąd został zgłoszony po raz pierwszy.
• ASSIGNED – PRZYDZIELONY – błąd zostaje przydzielony osobie, która będzie się nim zajmować. Może to być programista, analityk lub tester. W projektach prowadzonych w metodyce zwinnej, w ramach samoorganizujących się zespołów, to osoby same przypisują się do zadań. W metodykach klasycznych często do zadań odpowiedzialne osoby przypisuje np. kierownik.
• IN ANALYSIS – ANALIZA –  w niektórych przypadkach błąd potrzebuje analizy. Nie jest to obowiązkowy etap, gdyż nie każdy błąd potrzebuje analizy.
• DEFERRED – ODROCZONY – błąd został uznany za błąd, ale w tej iteracji nie będzie poprawiany. Zostanie odroczony i poprawiony w kolejnych sprintach/ wersjach. Ten status może być spowodowany wieloma czynnikami: brakiem czasu, niskim priorytetem znalezionego błędu itd.
• REJECTED (czasem WON’T DO) – ODRZUCONY – błąd został uznany jako bezzasadny i na tej podstawie odrzucony. Ten stan oznacza zamknięcie zgłoszenia bez naprawy.
• DUPLICATED – POWIELONY – w niektórych przypadkach (w szczególności gdy zespół testerski liczy więcej osób) istnieje możliwość powielenia błędu. W przypadku znalezienia takiego zgłoszenia, powielone zgłoszenie otrzymuje status DUPLICATED i prace nad nim nie są kontynuowane. Za błąd powielony możemy uznać dwa zgłoszenia, które mają tą samą przyczynę.
• IN DEVELOPMENT – OTWARTY (czasem można się spotkać z nazwą OPEN) – programista pracuje nad rozwiązaniem błędu.
• TEST READY (czasem możemy się spotkać z nazwą FIXED) – programista wprowadził niezbędne poprawki. Zgłoszenie gotowe jest do retestów. Zadania ze statusem TEST READY nie są przypisywane do osoby. Tester widząc zadanie z takim statusem, może je do siebie przypisać, zmienić mu status na IN TEST i przeprowadzić niezbędne testy.
• IN TEST (czasem możemy się spotkać z nazwą RETEST) – tester przeprowadza wszelkie niezbędne testy, w celu sprawdzenia czy błąd został naprawiony. W przypadku naprawienia błędu w niektórych przepływach wprowadza się stan SPRAWDZONY.
• CLOSED – błąd jest rozwiązany i usunięty, a wprowadzone zmiany zostały przetestowane z pozytywnym skutkiem.
• REOPEN – PONOWNIE OTWARTY – pomimo wprowadzenia zmian, rozwiązania i usunięcia problemu, problem po pewnym czasie wystąpił ponownie. W zależności od organizacji pracy zespołu albo otwieramy zamknięte zgłoszenie ze statusem REOPEN, albo tworzymy nowe zgłoszenie.

Jak wygląda przykładowy diagram przepływu błędu?

Poniżej przedstawiam podstawowy przepływ błędu w projekcie. W zależności od narzędzia lub metodyki nazwy etapów mogą się lekko różnić lub mogą być rozbite na drobniejsze etapy. Poniżej przedstawiony podstawowy przepływ jest wystarczający do obsługi przepływu błędu w projektach informatycznych.

Praktyczny przykład przepływu błędu

Aby lepiej zobrazować przepływ pokazany na powyższym wykresie. Wyobraźmy sobie następującą sytuację. Jako testerzy zostaliśmy poproszeni o przetestowania formularza do przesyłania przelewów, używanego w aplikacji bankowej. Aplikacja powinna wyglądać jak na zdjęciu (por. zdjęcie poniżej).

 Znaleźliśmy i zgłosiliśmy cztery poniższe błędy:

1. Kolor przycisku Dalej jest zielony, a na zdjęciu poglądowym widzimy, że powinien być czerwony.
2. Zauważyliśmy nadmiarowe pole Data wykonania w ostatniej sekcji formularza.
3. Po naciśnięciu przycisku Dalej nie obserwujemy żadnej akcji.
4. Po naciśnięciu przycisku Dalej nie obserwujemy żadnej akcji.

Przypadek 1.

W przypadku pierwszym przeanalizujemy pierwsze zgłoszenie. Zaobserwowaliśmy, że kolor przycisku Dalej jest inny niż w specyfikacji. Po naradzie zgłoszenie zostało uznane jako błąd, ale otrzymało niski priorytet, dlatego naprawa tego błędu została odroczona (DEFERRED).

Przypadek 2.

W przypadku drugim przeanalizujmy zgłoszenie drugie. Zauważyliśmy, że w formularzu pojawia się nadmiarowe pole Data wykonania. Jednak w trakcie analizy okazało się, że takie pole zostało przewidziane i miało zostać zaimplementowane. Problem pojawił się w komunikacji, ponieważ tester nie został powiadomiony o tej zmianie i uznał ją za błąd. Zgłoszenie nie zostało uznane jako zasadne i otrzymało status REJECTED.

Przypadek 3.

W przypadku trzecim widzimy, że zgłoszenie trzecie jest identyczne jak zgłoszenie czwarte. Dlatego otrzymuje status DUPLICATED.

Przypadek 4.

W zgłoszeniu czwartym zauważamy, że zgłoszenie jest zasadne, dlatego rozpoczynamy pracę nad nim. Pracujemy zgodnie z przepływem zobrazowanym na wykresie powyżej. 

Zgłoszenie zostało stworzone, posiada status NEW. Zostało uznane za zasadne i przypisane do osoby odpowiedzialnej. Programista rozpoczął pracę nad nim, rozpoczął analizę i naprawianie błędu. Programista uznał, że błąd został naprawiony i przekazał do sprawdzenia testerowi. Tester przypisuje do siebie zadanie i wykonuje niezbędne testy. Po wielu testach okazuje się, że błąd rzeczywiście już nie występuje, dlatego zgłoszenie jest zamykane.