Cykl życia błędu w testowaniu oprogramowania. Przebieg co się dzieje w procesie tworzenia oprogramowania, gdy znajdziecie błąd, jakie są jego dalsze losy. W tym wpisie zobaczycie jak wygląda taki proces, jakie są najważniejsze kroki w tym procesie. W zależności od wykorzystywanego narzędzia i metodyki tworzenia oprogramowania, kroki mogą mieć różny wygląd.
Błąd, bug, defekt, feature?
Żartobliwie możesz usłyszeć, że zgłoszony przez Ciebie element to nie bug to feature. Oczywiście w trakcie developmentu ciężko będzie obyć się bez błędów. Naszym zadaniem będzie jak najwięcej tych robaczków wyłapać przed wypuszczeniem produktu.
Czym jest cykl życia błędu?
Cykl z życia błędu to proces, czasami krótkotrwały a czasami bardzo czasochłonny. Proces ten rozpoczyna się od wykrycia błędu, usterki przez testera czy też innego członka zespołu. W modelowym projekcie błąd powinien zostać przydzielony a następnie poprawiany. Po przejściu retestów błąd może zostać zamknięty. Jak widzimy na poniższej grafice czasami też trzeba jakieś czynności powtórzyć. Zdarza się też, że usterka przez nas znaleziona jest tak duża, że może to wymagać analizy szerszego grona deweloperskiego.
Jak to wygląda.
Co dokładnie jest na grafice?
Nowy błąd (NEW) – błąd został znaleziony przez testera i zgłoszony. Błąd został zgłoszony po raz pierwszy.
Przydzielony – (ASSIGNED) błąd zostaje przydzielony osobie, która będzie się nim zajmować. W projektach prowadzonych np. w Agile w ramach samoorganizujących się zespołów, to osoby same przypisują się do zgłoszonych zadań. W metodykach klasycznych do zadań odpowiedzialne osoby przypisuje np. kierownik.
Odroczony – (DEFERRED) – zgłoszenie zostało uznane jako błąd, ale w obecnej iteracji (np. sprincie) nie będzie poprawiany. Przedmiotowy task zostanie odroczny i poprawiony w kolejnym sprincie czy przy wydawaniu kolejnej wersji. Powodem takie statusu może być rzecz najbardziej trywialna – czas. Drugim najpopularniejszym powodem jest niski priorytet błędu.
Odrzucony – (REJECTED) – błąd został odrzucony, został zamknięty bez zgłoszenia poprawy.
Powielony – (DUPLICATED) – taka sytuacja zdarzyć się może gdy w zespole mamy kilku testerów, bądź też bogaty backlog z takimi zgłoszeniami. Za błąd powielony możemy uznać takie zgłoszenia, które mają identyczną przyczynę.
Analiza – (IN ANALYSIS) – zdarza się, że zgłoszony przez Was bug jest taki, że konieczna jest analiza. Czasami też zgłoszona przez Was usterka może być przyczynkiem do bardzo dużej pracy zespołu.
Przydzielony – nie zawsze opisywane, ale służy to temu by zaznaczyć, że ktoś Wasze zgłoszenie musi przypisać do siebie lub je otrzymać do wykonania.
Otwarty – (OPEN) – osoba przydzielona zapoznaje się ze zgłoszeniem i podejmuje decyzję czy poprawiać buga czy też konieczna jest szersza analiza zgłoszenia.
Development – programista poprawia funkcjonalność tak by działała jak to opisane w projekcie/dokumentacji czy kryteriach akceptacji.
Code review – kolejny bufor, który pozwala wyłapać błędy. Sprawdzanie kodu programiście przez programistę.
Przekazanie do testów (TEST READY bądź FIXED) – po poprawkach i pozytywnm przejściu code review zgłoszenie jest gotowe do retestów.
Retesty – (IN TEST lub RETEST) – ponownie nasza rola. Weryfikujemy czy błąd został poprawiony i funkcjonalność działa tak jak powinna. W zależności od organizacji, posiadanych testów automatycznych mogą tutaj wystąpić różne dodatkowe czynności.
Ponowne otwarcie – (REOPEN) – mimo wprowadzenia zmian, przejścia code review problem nadal występuje. Błąd może być nadal taki sam jak wcześniej, może występować w mniejszym zakresie. Przykład – frontend developer miał poprawić działanie przycisku na urządzeniach mobilnych (określasz jakie). Po poprawce button działa na androidzie, nie działa zaś na iOS.
Gotowe (zamknięte) – (CLOSED) – zgłoszony błąd został usunięty i przeprowadzone testy zakończone zostały pozytywnie.
Dodatek.
W ramach swojej pracy możemy spotkać wiele różnych statusów, nie wymienionych w powyżej sekcji. Poniżej kilka dodatkowych statusów.
Moved (Przeniesiony) – defekt jest charakterystyczny dla innego projektu. Przeniesiono go do bazy danych błędów np. innego zespołu, czy też na tablicę innego produktu.
Worksforme – wszelkie próby odtworzenia błędu nie powiodły się. Przyczyny wcześniej zgłoszonego błędu nie są znane. W przypadku ponownego pojawia się takiego buga i uzyskaniu większej ilości danych, można go ponownie otworzyć.
Podsumowanie.
Przedstawiona w niniejszym wpisie metodyka pracy – cykl życia błędu w testowaniu oprogramowania – może się różnić w Waszej organizacji. Jest tutaj zarys najważniejszych czynności jakie występują po tym jak zgłosicie błąd. Więcej informacji dla początkujących osób znajduje się w dziale „Jak zostać testerem”. Ważnym też aspektem jest to by poprawnie zgłaszać błędy o czym piszemy w odrębnym artykule.
