Jak napisać zgłoszenie błędu (+ darmowy szablon do pobrania)

Umiejętność tworzenia skutecznego zgłoszenia błędu jest ważną częścią pracy testera oprogramowania, który ma za zadanie zapewniać jakość, dlatego poświęcamy dużo czasu na rejestrowanie błędów w naszych narzędziach do śledzenia błędów. Znalezienie błędu może być ekscytujące, zwłaszcza jeśli dotyczy interesującego scenariusza. Jednak sposób jego zgłoszenia może być równie ważny jak jego wpływ na system.

Nieprawidłowo napisane zgłoszenie błędu może powodować wiele napięć między członkami zespołu, szczególnie między testerami a programistami, co może prowadzić do blokad w usuwaniu błędów i ostatecznie pogorszyć doświadczenia użytkownika.

W tym artykule omówię najważniejsze szczegóły, takie jak:

• Opanowanie zgłoszeń błędów: Poznaj kluczowe elementy, które powinno zawierać każde skuteczne zgłoszenie błędu, aby usprawnić komunikację i przyspieszyć naprawy.
• Lepsza współpraca w zespole: Dowiedz się, jak dobrze napisane zgłoszenia błędów zapobiegają napięciom między testerami a programistami, prowadząc do sprawniejszej pracy.
• Darmowy szablon do pobrania: Pobierz bezpłatny szablon do śledzenia błędów, aby szybko rozpocząć skuteczny proces zgłaszania błędów.

Kluczowe elementy zgłoszenia błędu

Niezależnie od rodzaju testowanej aplikacji — czy jest to aplikacja desktopowa, internetowa, mobilna czy projekt API — istnieją kluczowe elementy, które powinno zawierać każde dobre zgłoszenie błędu. Większość oprogramowania do śledzenia błędów udostępnia pola dla tych elementów, w tym:

• Identyfikator: Jeśli korzystasz z narzędzia do zarządzania projektami, takiego jak Jira, identyfikator zostanie automatycznie przypisany do każdego nowego otwartego zgłoszenia. Dostępne są również narzędzia do zarządzania testami dla Jiry służące do śledzenia błędów
• Tytuł/opis: Jest to krótki opis problemu. Powinien być wystarczająco zwięzły, aby łatwo się go czytało, ale jednocześnie na tyle szczegółowy, by inni mogli zrozumieć, na czym polega problem. Na przykład: „sortowanie elementów według ceny nie działa po zastosowaniu filtra”. 
• Kroki odtworzenia: Uwzględnij tutaj jak najwięcej istotnych szczegółów. Upewnij się, że każda osoba próbująca odtworzyć problem lub zweryfikować poprawkę będzie mogła to zrobić, wykonując podane kroki. Nie pomijaj kroków, zakładając, że wszyscy domyślą się, iż powinni wykonać określone czynności, nawet jeśli nie zostały one wymienione; uwzględnij je w zgłoszeniu błędu. 
• Oczekiwane rezultaty: Ponownie, nie zakładaj, że inni już wiedzą, jak aplikacja powinna działać. Oczywiście, jeśli po naciśnięciu przycisku w interfejsie użytkownika pojawi się wyjątek, wiesz, że nie jest to oczekiwane. Nie powiedziałbym jednak, że oczekiwanym rezultatem jest „wyjątek nie zostaje zgłoszony”, lecz raczej opis czynności, którą powinien wykonać przycisk, czyli „otwiera się okno dialogowe ustawień”.
• Rzeczywiste rezultaty: To wyjaśnia się samo — należy opisać, co dzieje się w aplikacji po wykonaniu wszystkich kroków odtworzenia.
• Ważność: Określa wpływ błędu na AUT.
• Priorytet: Określa, jak szybko należy naprawić błąd. Wyższy priorytet oznacza, że błąd powinien znaleźć się wyżej w rejestrze zadań i zostać naprawiony wcześniej.

Inne ważne informacje, które należy uwzględnić 

Oprócz wymienionych wyżej elementów istotne mogą być także inne informacje, szczególnie podczas wprowadzania danych do narzędzia do zgłaszania błędów. Mogą one zależeć od rodzaju projektu, jego wymagań, a nawet od samego błędu:

• Wersja oprogramowania: Numer kompilacji, w której zidentyfikowano błąd. Może to pomóc zawęzić kompilacje, w których problem został potencjalnie wprowadzony, oraz zidentyfikować kod, który go spowodował.

• Załączniki: Nie zawsze są potrzebne lub dostępne, ale zazwyczaj dostarczają wielu cennych informacji. Warto dołączyć zrzuty ekranu lub nagrania przedstawiające znaleziony problem, pliki dziennika, ślady stosu, żądania i odpowiedzi sieciowe itp. 
• Dane testowe: Czasami znalezione przez nas błędy można odtworzyć tylko dla określonych zestawów danych. Jeśli tak jest, pamiętaj, aby je uwzględnić — albo w krokach odtworzenia (na przykład „zaloguj się za pomocą użytkownika andreea@theqalead.com”), albo w przeznaczonym do tego polu narzędzia do śledzenia błędów.
• Szczegóły środowiska: Jeśli błąd można odtworzyć tylko w określonym systemie operacyjnym, przeglądarce lub środowisku programistycznym, wspomnij o tym.  

Wskazówki dotyczące tworzenia dobrego zgłoszenia błędu

• Ogranicz się do jednego błędu w jednym zgłoszeniu. Jeśli odkryjesz więcej błędów w tych samych obszarach, możesz połączyć je ze swoim systemem śledzenia zgłoszeń. Uwzględnienie więcej niż jednej usterki może powodować nieporozumienia i opóźnienia w potencjalnym naprawianiu błędów.
• Sprawdź w swoim systemie śledzenia, czy błąd nie został już zgłoszony. Jeśli zgłoszenie już istnieje, dodaj wszelkie istotne informacje, które znalazłeś, a których nie uwzględniono w pierwotnym zgłoszeniu błędu.
• Spróbuj odtworzyć błąd więcej niż raz. Możesz spróbować znaleźć najkrótszy sposób na jego odtworzenie (z użyciem najmniejszej liczby kroków).
• Nie zagłębiaj się w nieistotne szczegóły. Zgłoszenie błędu i instrukcje powinny być łatwe do przeczytania i wykonania.
• Nie zakładaj, dlaczego występuje błąd (chyba że masz stuprocentową pewność, co go spowodowało).

Szablon zgłoszenia błędu

Teraz chciałbym udostępnić kilka szablonów zgłoszeń błędów. Możesz je skopiować lub zmodyfikować zgodnie z potrzebami swojego projektu.

Szablon śledzenia błędów w Jira

Jira to bardzo popularne narzędzie firmy Atlassian do śledzenia zgłoszeń. Jeśli Twój zespół z niego korzysta, typ zgłoszenia błędu jest prawdopodobnie już skonfigurowany. Jako tester lub kierownik zespołu programistycznego możesz skonfigurować przepływ pracy związany ze śledzeniem błędów w cyklu życia błędów (jest to jedna z wielu zalet oprogramowania do śledzenia zgłoszeń). 

Możesz również dodać pola niestandardowe w Jira, na przykład dotyczące środowiska lub unikalnego pola, w którym dodawana jest informacja o testowanej funkcjonalności. Możesz też dodać domyślny opis zawierający wszystkie informacje, które mają być uwzględniane w każdym zgłoszeniu błędu. Oto opis, który utworzyłem:

Od tej pory, gdy będę chciał utworzyć nowy błąd, te informacje będą już wstępnie wypełnione. Oto mój szablon błędu w Jira, wykorzystujący pola niestandardowe i domyślny opis:

Zawiera on najważniejsze informacje, które, jak wspomnieliśmy, powinno zawierać zgłoszenie błędu:

• Tytuł („Przykładowy błąd”)
• W opisie: warunki wstępne, kroki odtworzenia oraz oczekiwane i rzeczywiste wyniki
• Pole niestandardowe dotyczące środowiska
• Waga i priorytet wybrane z rozwijanych list zawierających wstępnie zdefiniowane wartości
• Pozostawiłem puste pole osoby przypisanej. W zależności od przyjętych w projekcie zasad nowe błędy mogą być automatycznie przypisywane konkretnemu członkowi zespołu albo osoba, która zaczyna nad nimi pracować, może przypisać je sobie
• Etykieta — może być przydatna na przykład wtedy, gdy chcesz śledzić, jaka funkcjonalność została dotknięta problemem
• Termin realizacji — zadanie może nie zostać wykonane, dopóki nie ustalisz priorytetów elementów w rejestrze prac
• Osoba zgłaszająca (w tym przypadku pole jest automatycznie wypełniane użytkownikiem Jira, który utworzył błąd)

Opcjonalnie Jira oferuje kilka integracji, a błąd można połączyć z przypadkami testowymi, gałęziami Git, a nawet żądaniami scalenia.

Możesz również użyć ich szablonu śledzenia błędów jako szablonu projektu, jeśli potrzebujesz Jira wyłącznie do śledzenia usterek i nie pracujesz w środowisku zwinnym.

Szablon śledzenia błędów w Excelu

Niektóre zespoły mogą używać arkuszy kalkulacyjnych jako systemu śledzenia błędów. Uważam je za przydatne w przypadku bardzo małych projektów, w których konfigurowanie narzędzia do śledzenia zgłoszeń nie jest po prostu warte zachodu, lub do zgłaszania błędów w nowych funkcjach, które są nadal w fazie opracowywania. 

Możesz użyć Arkuszy Google/ Dokumentów Google albo programu Microsoft Excel/Word — w każdym przypadku szablon błędu może wyglądać tak:

Kolumny odzwierciedlają informacje, które powinno zawierać zgłoszenie:

• Identyfikator (Excel będzie wiedział, jak automatycznie zwiększać tę wartość za każdym razem, gdy zostanie dodany nowy wiersz)
• Tytuł
• Kroki umożliwiające odtworzenie błędu
• Oczekiwane i rzeczywiste rezultaty
• Imię i nazwisko osoby zgłaszającej
• Dotkliwość i priorytet błędu — tutaj użyłem list rozwijanych, ponieważ wartości powinny być wstępnie ustalone
• Środowisko
• Dodatkowe informacje: to miejsce na wszystko, co warto odnotować, a co nie pasuje do pozostałych kolumn

Końcowe przemyślenia

Umiejętność tworzenia dobrych raportów o błędach w oprogramowaniu jest niezbędna dla testerów oprogramowania, dlatego zwróć szczególną uwagę na opisane powyżej najlepsze praktyki. Możesz również skorzystać z przedstawionych przeze mnie przykładów szablonów systemów śledzenia błędów. Można je dostosować do różnych używanych narzędzi, takich jak Trello czy Asana.

Jeśli spodobała Ci się ta treść, zasubskrybuj newsletter The QA Lead, aby być na bieżąco z najnowszymi wiadomościami i trendami w procesie testowania oprogramowania!