Jak poprawnie zgłosić błąd?

Nie ważne czy jesteś testerem manualnym, czy piszesz testy automatyczne – znaleziony błąd należy prawidłowo zaraportować do poprawki. Poprawne zgłoszenie błędu wcale nie jest taką trywialną sprawą. Musimy poznać kilka podstawowych informacji, które sprawią, że nasz raport błędu będzie jasny, czytelny i szybki w odbiorze. Warto spędzić trochę czasu na poznanie dobrych praktyk tworzenia raportów ze znalezionych błędów, gdyż w ten sposób możemy uniknąć odrzuceń zgłoszeń przez developerów. Dlaczego developerzy zwykle odrzucają zgłoszenia naszych defektów? Często kluczowym czynnikiem jest właśnie to, że błąd jest źle opisany, nie można na podstawie zgłoszenia zreplikować błędu, bądź developer po prostu nie rozumie istoty defektu i zwyczajnie go ignoruje. Źle zgłoszone defekty często również są punktem zapalnym między developerem a testerem – dlatego starajmy się raportować błędy tak, by były jasne i łatwe w odbiorze przez osoby docelowe. Zatem spójrzmy jak powinien wyglądać dobry raport błędu.

Wyróżniłem 10 najważniejszych elementów, o których nie można zapominać.

Raport błędu powinien posiadać:

1. Unikalny identyfikator.

Trywialny, ale bardzo istotny element. Każde zgłoszenie powinno otrzymać swój unikalny identyfikator, gdyż tylko w ten sposób – szybko i jednoznacznie możemy odwoływać się do konkretnych zgłoszeń. Na szczęście większość popularnych systemów typu Bug Tracker , zawiera wbudowany, automatycznie inkrementowany identyfikator zgłoszeń.

• Krótki, konkretny tytuł zgłoszenia.

Bardzo ważny element zgłoszenia – tytuł. W kilku słowach powinniśmy nakreślić, jakiego konkretnie problemu dotyczy zgłoszenie. Już na podstawie tych kilku tytułowych słów, osoby zainteresowane powinny wstępnie orientować się, czego konkretnie dotyczy zgłoszenie.

• Opis zgłoszenia

Opis zgłoszenia powinien jednoznacznie i bardzo szczegółowo określać czego dotyczy dane zgłoszenie, oraz jakie należy wykonać kroki, by odtworzyć zgłaszany błąd. Najlepiej opis dojścia do błędu ubrać w listę punktowaną z sekwencją kroków do wykonania.

Np.

1. Wejdź na stronę http://selenium-shop.pl/
2. Kliknij zakładkę moje konto
3. Wprowadź logi i hasło – zaloguj się.
4. Zweryfikuj tytuł na stronie na której jesteś.

• Oczekiwany / rzeczywisty wynik.

W kilku zdaniach należy określić jakiego wyniku się spodziewamy i jaki wynik otrzymujemy.

Np.

• Spodziewany wynik: Jestem zalogowany. Znajduję się na stronie głównej sklepu
• Rzeczywisty wynik: Strona zgłasza błąd 404

• Priorytet zgłoszenia:

Każde zgłoszenie powinno otrzymać jakiś priorytet. Na jego podstawie developer wie w jakiej kolejności rozwiązywać zgłoszone błędy i jak są one znaczące dla całego projektu. Można przyjąć np. taką skalę priorytetów:

• Bloker – nie można przeprowadzić testu, bądź błąd blokuje działanie aplikacji
• Krytyczny – awaria aplikacji, błąd kluczowych elementów aplikacji
• Wysoki – błąd o dużym znaczeniu dla aplikacji
• Średni – błąd, który nie jest poważnym zagrożeniem aplikacji, ale który należy stosunkowo szybko naprawić
• Niski – niewielki błąd, który nie ma znaczenia dla poprawnego działania kluczowych funkcji aplikacji

• Środowisko/ konfiguracja

Informacja o środowisku i dokładnej konfiguracji środowiska, na którym został znaleziony błąd. Jest to bardzo ważna informacja, gdyż trzeba mieć świadomość, że błąd może dotyczyć bezpośrednio środowiska, bądź jego konkretnej konfiguracji. Mogą zdarzyć się sytuacje, że na środowisku testowym błąd występuje, a na środowisku developerskim, czy produkcyjnym tego błędu nie uda się odtworzyć.

• Osoba przypisana do zgłoszenia

Zawsze przypisujmy konkretną osobę, lub konkretną grupę osób do obsługi danego zgłoszenia. Najczęściej będzie to zdefiniowany zespół developerski bądź zdefiniowany developer. Z doświadczenia mogę podpowiedzieć, że lepiej jest przypisać konkretną osobę, niż grupę osób, gdyż czasami, kiedy zgłoszenie wisi na grupie osób – gdzieś odpowiedzialność za zgłoszenie może się rozmyć. Ten problem nie występuje, gdy od razu wskażemy konkretnego programistę. Nawet jeśli wybrany programista nie będzie mógł zrealizować danego zgłoszenia, to najczęściej sam przepnie zgłoszenie do odpowiedniejszej osoby.

• Zrzut ekrany/ nagranie video/ logi / dodatkowe pliki

Bardzo istotny element, chociaż często pomijany. Zdarzają się takie sytuacje, ze błąd nie jest replikowalny (możliwy do odtworzenia), bądź pojawia się tylko „od czasu do czasu”. Mogą zdarzyć się sytuacje, że nawet bardzo dokładnie opiszmy konkretny błąd, ale developer odrzuci zgłoszenie, ponieważ u niego ten błąd nie występuje (nie możliwy do odtworzenia). Zatem wspominane pliki takie jak zrzuty ekranów, nagrania video, logi – w takich wypadkach będą „dowodami” na to, iż faktycznie wskazany błąd ma miejsce i pojawia się (nawet jeśli nie zawsze).

• Status błędu

Krótka najczęściej predefiniowana wartość, mówiąca nam jaki jest konkretny, status naszego zgłoszenia,

np.

• Nowy
• W trakcie naprawy
• Naprawiony
• Do retestu
• Zweryfikowany
• Zamknięty
• Otwarty ponownie
• Odrzucony

• Wersja/wydanieaplikacji

Koniecznie musimy również uzupełnić zgłoszenie o wersję aplikacji, na której został wykryty błąd. Tylko w ten sposób developer będzie wiedział, gdzie należy szukać błędu i jego rozwiązania.

Mój TIP:

Przed zgłoszeniem błędu zawsze sprawdź w systemie, czy już taki sam błąd nie został zgłoszony przez innego testera. Często zdarza się, że duplikujemy zgłoszenia i w ten sposób sami sobie robimy bałagan w projekcie – programiści naprawdę nie cierpią zduplikowanych zgłoszeń! 

Po zgłoszeniu błędu, tuż przed jego akceptacją – przejrzycie raz jeszcze zgłoszenie, zobaczcie czy na pewno jest kompletne, czy załączyły się wszystkie dodatkowe załączniki, oraz czy na pewno jest przypisane do właściwej osoby. Spójrzcie na to zgłoszenie i zadajcie sobie pytanie, czy jest na tyle szczegółowe, że developer nie będzie musiał zadawać dodatkowych pytań ( które zwykle znacznie wydłużając cały proces identyfikacji i naprawy błędu).

Autor: Tomasz Stelmach