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ń.

Czym jest defekt?

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 trakcie których 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?

diagram cykl życia defektu
Diagram - 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ż nie zmieniany 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.

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz