Jak zgłaszać błędy?

Przed przeczytaniem tego artykułu warto jest się zapoznać z Co to jest błąd, defekt, awaria?

Jak poprawnie zgłaszać błędy?

Szukanie błędów to tylko jedna strona medalu. Aby testowanie było „kompletne” i niosło jakąś wartość, należy znalezione błędy zgłosić. Dodatkowo, samo zgłoszenie powinno być odpowiednio przygotowane. Zgłoszenia błędu nie należy traktować jako podnoszenia jakości – możemy o niej mówić dopiero, wtedy gdy błąd zostanie naprawiony.

Dobry tester to ten, który potrafi w jasny sposób zgłosić znaleziony błąd. Każdy członek uczestniczący w projekcie nie powinien mieć problemu z jego zrozumieniem. Ważne jest, aby zgłoszony błąd nie atakował członków zespołu. Zgłoszenie powinno być neutralne i nie zawierać pretensjonalnego przesłania czy sugestii, że ktoś zawalił sprawę.

Dobre praktyki zgłaszania błędu

Nie jesteś pewien czy jest to błąd mimo przeczytania dokumentacji.

  • Możliwe, że też jej nie ma. Warto zasięgnąć wtedy rady analityka czy Testera starszego stażem.. Jeżeli nie ma takiej możliwości, to zawsze lepiej zgłosić taki błąd. Może się później okazać, że błąd był istotny, a Ty z powodu wątpliwości go nie zgłosiłeś.

Jeden błąd jedno zgłoszenie.

  • Pamiętaj, aby nie komplikować zgłoszenia. Powinno być ono proste i przejrzyste. Im więcej błędów  będziesz chciał umieścić w zgłoszeniu, tym bardziej ucierpi na tym przejrzystość. Zgłoszenie kilku błędów w jednym może do wielu miesięcy przedłużyć proces ich naprawiania.  Poza tym, trudno będzie nam określić postęp testów.

Zanim zamkniesz błąd, zrób retest.

  • Retest polega na odtworzeniu zgłoszonego błędu po jego naprawieniu. Jako Tester musisz mieć pewność, że zgłoszony przez Ciebie błąd został naprawiony i możesz zamknąć zgłoszenie.

Stosuj szablon rejestrowania błędów.

  • Aby proces raportowania błędów przebiegał sprawnie, warto mieć dostosowany do swoich potrzeb szablon. Jeżeli każde zgłoszenie będziesz raportować rożnie, to na pewno czegoś zapomnisz. W przypadku bug trackerów masz określony szablon, którego elementy możesz modyfikować wedle swoich potrzeb.

Pilnuj swoich zgłoszeń.

  • Jeżeli z Twoimi zgłoszeniami długo nic się z nimi nie dzieje, należy się tym zainteresować i zapytać osoby, która została wyznaczona do ich naprawy o aktualny stan zgłoszeń. Może się okazać, że zostały naprawione, tylko programista zapomniał zmienić ich status.

Kroki do reprodukcji błędu.

  • Najlepiej, aby kroki były wypunktowane i konkretne. Długie i skomplikowane opisy utrudnią programistą odtworzenie błędu. Warto zadbać, aby tekst wyglądał na uporządkowany i przejrzysty. Jeżeli użyłeś jakiś danych testowych, to również je zamieść. Może się okazać, że ich rodzaj ma znaczenie w trakcie reprodukcji błędu.

Przeczytaj jeszcze raz.

  • Zanim zatwierdzisz zgłoszenie, przeczytaj je i upewnij się, że zawiera wszystkie istotne informacje. Jeżeli będzie czegoś brakować, to nie unikniesz dodatkowych pytań od programistów czy dodatkowych testów. Wydłuży to nie potrzebnie czas rozwiązania błędu.

Zdiagnozuj błąd.

  • Pomyśl, jaka możne być przyczyna błędu. Zrób dodatkowe testy, aby zawęzić pole poszukiwań. Programiści będą Ci  wdzięczni, że wykonałeś tę część pracy. Może się okazać, że wykryjesz inne błędy w tym samym miejscu systemu.

Szablon poprawnego zgłoszenia błędu

Jak będzie wyglądało poprawnie zaraportowane zgłoszenie zależy od firmy, projektu i zespołu. Przy tworzeniu zgłoszenia błędu warto się trzymać poniższego szablonu i modyfikować go wedle własnych potrzeb.

Tytuł – powinien być krótki i treściwy. Mówić dokładnie co nie działa i wskazywać miejsce błędu. Należy unikać w tytule ogólników typu „formularz nie działa”, „system nie działa” „przycisk nie działa”. Zamiast tego można napisać „w formularzu rejestracji przycisk ‘przypomnij hasło’ nie ma podpiętego linku w kodzie HTML”.

Środowisko – tutaj wpisz środowisko, w jakim wystąpił błąd. Może być to rodzaj systemu (Windows czy Mac) przeglądarka i jej wersja. Zależnie od wymagań i produktu można dodać model telefonu (jeżeli testujemy aplikację mobilną). Znaczenie może mieć również to, czy błąd został wykryty na środowisku Developerskim czy Testowym.

Priorytet – jak ważny jest błąd i jak duży ma wpływ na system czy funkcjonalność. Standardowo można wyróżnić następujące poziomy:

  • Bloker – błąd, który uniemożliwia działanie i dalsze testowanie
  • Krytyczny – błąd, który uniemożliwia poprawne działanie.
  • Ważny – błąd, który sprawia, że kluczowa funkcjonalność nie zachowuje się zgodnie z założeniami i trzeba z niej korzystać według specjalnych reguł.
  • Średni – niewielkie zakłócenia w korzystaniu z funkcjonalności, które nie są kluczowe z punktu widzenia biznesowego.
  • Mały – znikome znaczenie błędu i niezaburzające korzystanie z funkcjonalności i nie mający wpływu na procesy biznesowe.

Powtarzalność – czy jesteś w stanie zawsze odtworzyć błąd, czy pojawia się on losowo.

Warunek wstępny – jakie warunki muszą być spełnione, aby móc przystąpić do reprodukcji błędu.

Dane Testowe – jakich wartości użyłeś do wywołania błędu. W niektórych przypadkach tylko konkretna wartość wywołuje błąd, a inne wartości już nie. Jeżeli tego nie uwzględnisz w zgłoszeniu, to prawdopodobnie wróci ono do Ciebie jako “u mnie działa”.

Kroki – kroki jakie należy wykonać, aby odtworzyć błąd.

Rzeczywisty rezultat – Jak zachowała się funkcjonalność?

Oczekiwany rezultat – Jak powinna się zachować funkcjonalność.

Zrzuty ekranu/video – obraz mówi więcej niż tysiąc słów. Czasami wystarczy tylko spojrzeć i już wiesz, o co chodzi i gdzie szukać. Warto do każdego błędu w miarę możliwości załączać screeny bądź video. Ważne, aby załączone screeny były odpowiednio opisane. Często wystarczy zaznaczenie na czerwono miejsca błędu.

Uwagi – twoje podejrzenia co do powodu występowania błędu. Możesz również dodać uwagi odnośnie swojej opinii jak można usprawnić działanie funkcjonalności.

Po zgłoszeniu błędu warto upewnić się, czy zawiera ono wszystkie punkty właściwego zgłoszenia:

  1. Czy wszystkie pola zostały uzupełnione i nie brakuje żadnych ważnych informacji?
  2. Czy w opisie kroki są jasne, wypunktowane i prowadzą do reprodukcji błędu?
  3. Czy opisałeś tylko jeden błąd (Lepiej unikać zawierania kilku błędów w jednym zgłoszeniu)?
  4. Czy zgłoszenie zawiera zrzut ekranu i czy jest on opisany?
  5. Warto sprawdzić, czy wykryty defekt nie został już zgłoszony (nie ma sensu zgłaszać duplikatu)
  6. Czy tytuł jasno opisuje problem, jaki występuje i nie jest za długi oraz ogólny?
  7. Czy uwzględniłeś istotne informacje odnośnie środowiska występowania błędu?
  8. Czy błąd zgłosiłeś w obiektywny sposób (nie krytykując nikogo z zespołu)?
  9. Przeczytaj powoli zgłoszenie jeszcze raz i popraw wszelkie niedopatrzenia.

Przykładowe zgłoszenie w JIRA

Przykład błędu w JIRAIm więcej napiszesz zgłoszeń tym lepiej będzie Ci to wychodzić. Dobrym miejscem, aby poćwiczyć jest uTest – testowane w tłumie

Udostępnij i podziel się z innymi!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Subscribe
Powiadom o
guest

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

10 komentarzy
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
K

“Długie i skomplikowane opisy utrudnią programistą odtworzenie błędu.” – jestę programistą, jesteśmy programistami 😉

kin

A jak wygląda życie takiego zgłoszenia w Jirze i generalnie proces ? Zgłoszenie trafia bezpośrednio do programisty? Co on z tym robi? Wraca z komentarzem do testera, czy zmienia status na feedback i poprawia, jak poprawi to zamyka?

kin

Dzięki! Jak zawsze bardzo wyczerpująca i pomocna odpowiedź na wszystkie moje pytania z poziomu początkujący tak bardzo. Jesteś nieoceniony. 🙂

kin

Super! To czekam na publikację, chętnie poczytam. 🙂

kin

W czym w zasadzie różni się zgłoszenie błędu i test case. Chodzi mi tutaj o opis, jakie pola dodajemy. Bo wydaje mi się, że treść zgłoszenia błędu jest bardziej rozbudowana niż napisanie test case. Ciężko na początku jest to wyłapać jeśli nie bazuje się jeszcze na wiedzy praktycznej.

Kin

A czy zawsze schemat jest taki, że powstaje test plan potem scenariusz i do scenariusza test cases. Czy zdarza się tak, że od razu robi się test cases bez scenariusza? Jeśli mogę coś zasugerować, to do kompletu artykułów o błędzie i test case przydałby się jeszcze jeden o pisaniu scenariuszy. A tak nawiasem mówiąc te dwa bardzo dobre i przydatne!