W tym wpisie postaram się opisać, jak wygląda typowy cykl życia defektu. Odpowiem również na pytanie, czy warto przechowywać dane na temat zgłoszeń.
Co to jest defekt, błąd?
Mówiąc wprost, jest to różnica pomiędzy tym, jak aplikacja została opisana w dokumentach analizy a aplikacją, którą testujemy. Pracując jako tester, spotkasz się z określeniami „błąd” i „bug” znaczącymi to samo co defekt. A czasami usłyszysz też zdanie „To nie bug to feature” 🙂
Cykl życia defektu rozpoczyna się od jego zgłoszenia do systemu.
Może to być Mantis, Jira czy inny system używany w firmie. Zgłaszając błąd, zwróć uwagę, by opisać go dokładnie. W artykule o współpracy testera z programistą możesz przeczytać, co zrobić by nie było konfliktów w zespole. Prawidłowo opisane defekty pozwolą Ci zbudować dobrą współpracę z zespołem. Cykl życia defektu składa się z etapów, w których trakcie zmieniany jest status zgłoszenia. Poniżej przeczytasz na temat najczęściej używanych statusów w kolejności ich używania / ustawiania w systemie.
Jak wygląda cykl życia defektu?
W momencie, w którym dodasz błąd znaleziony w aplikacji do narzędzia, zgłoszenie otrzymuje status OTWARTY.
W następnym kroku defekt zostaje PRZYDZIELONY do programisty, który ma doprowadzić błąd do statusu ZAMKNIĘTY.
Na czas poprawiania, defekt ma przypisany status IN PROGRESS.
Z chwilą ukończenia prac nad błędem programista zmienia jego status na IN REVIEW. Oznacza to, że zakończył pracę, uważa, że defekt jest poprawiony i chce, by inny programista sprawdził zmiany w kodzie.
Błąd, który nie przeszedł review, wraca do statusu OTWARTY i ponownie przechodzi przez kolejne etapy powyższego diagramu.
Jeśli jednak defekt przeszedł przez code review, to trafia na listę błędów do weryfikacji i OCZEKUJE NA RETESTOWANIE przez nas testerów.
Na tym etapie w zależności czy uda się nam go odtworzyć, czy też niezmieniany jest jego status na ZAMKNIĘTY lub OTWARTY.
Czy powinniśmy zapomnieć o zgłoszeniu, które zostało przez nas zamknięte?
Moim zdaniem nie powinniśmy zapominać o zgłoszeniach, które kiedyś zgłosiliśmy w kontekście projektu. Informacje, które możemy zdobyć dzięki odpowiedniemu przechowywaniu danych historycznych, mogą nam dać bardzo cenne wnioski, np. o stanie kodu w aplikacji. Zdarza się, że wraca do nas „jak bumerang” to samo zgłoszenie lub bardzo podobne. W takiej sytuacji powinniśmy się zastanowić nad tym, czy testy wykonywane przez nas są wystarczająco dokładne. Wracające zgłoszenie może świadczyć również o braku stabilności kodu aplikacji. Dobrze jest wówczas dodać taki błąd jako przypadek do testów akceptacyjnych.
