Jak zgłaszać błędy?

Jak poprawnie zgłaszać błędy?

Szukanie błędów to dopiero 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 podnoszenie jakości. Dopiero, wtedy gdy błąd zostanie naprawiony, możemy mówić o podniesieniu jakości.

Dobry tester to taki, który potrafi w jasny sposób zgłosić znaleziony błąd. Każdy członek uczestniczący w projekcie nie powinien mieć problemu ze zrozumieniem błędu. 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 sugerować, ż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 co sądzi na ten temat. 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ść. Takie zgłoszenie kilku błędów w jednym możne się ciągnąc miesiącami, zanim wszystkie zostaną naprawione.  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 informację. 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ż czy błąd został wykryty na środowisku Developerskim albo 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 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 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

Im więcej napiszesz zgłoszeń tym lepiej będzie Ci to wychodzić. Dobrym miejscem, aby poćwiczyć jest uTest.

Jak zgłaszać błędy

Polecane wpisy

Udostępnij i podziel się z innymi!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Dodaj komentarz

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Powiadom o