Jak poprawnie zgłaszać błędy to chyba podstawa podstaw pracy testera. Twoje zgłoszenie musi być tak przedstawione by każdy mógł go odtworzyć w łatwy sposób. Pisząc każdy mam na myśli nie tylko drugiego testera, ale także Dewelopera, Product Ownera czy innego członka zespołu.
Dlaczego to wszystko jest tak ważne?
Raportując błąd w Waszym systemie np. w Jirze, opisz go w taki sposób, by każdy go umiał zreplikować. Np. programista otrzymujący go do weryfikacji i poprawy, nie spędził zbyt wiele czasu na zrozumienie co miałeś na myśli. Oczywiście może zdarzyć się tak, że coś może wymagać doprecyzowania. Nieprecyzyjne opisanie błędu powodować może poprawę nie tej funkcjonalności o której mówiliśmy i programista dowie się o tym np. po retestach.
To co ma być w zgłoszeniu.
- Tytuł zgłoszenia:
– powinien być krótki, ale treściwy i konkretny. Może zawierać słowo kluczowe obrazujące problem. - Priorytet błędu:
Musisz określić czy to co znalazłeś jest krytycznym problemem aplikacji czy też poziom priorytetu jest niższy. Idąc przykładem Jiry mamy priorytety w postaci Lowest-Low–Medium–High-Highest - Urządzenie:
Gdzie ten błąd powstał – np. Windows 10, przeglądarka Google Chrome v. 83.0, czy też Samsung Galaxy Note 10, andorid 10, przeglądarka Chrome v. XX. - Środowisko:
Jeżeli posiadacie środowiska stagowe to koniecznie określ na którym stage testowałeś. - Wersja:
Jeżeli posiadacie wersjonowane oprogramowanie koniecznie zwróć na to uwagę przy zgłoszeniu błędu; - Opis:
Krótki, konkretny który pomoże czytającemu zdobyć informację o co chodzi w błędzie. Wskazać też czy błąd jest powtarzalny zawsze czy np. częstotliwość jego odtworzenia nie jest 100 procentowa. - Kroki:
Dokładnie opisana instrukcja krok po kroku co trzeba zrobić by taki błąd wystąpił. Kroki muszą być na tyle zrozumiałe, by deweloper w trakcie poprawki potrafił go zreprodukować i móc np. zdebugować co się dzieje. - Obecny rezultat
Krótki opis co się dzieje obecnie po wykonaniu wskazanych wyżej kroków. - Oczekiwany Rezultat
Wytłumaczenie jaki jest oczekiwany rezultat po przejściu kroków o których pisałeś wcześniej. - Załączniki
Wszelkiego rodzaju dodatkowe informacje w postaci zrzutów ekranu, filmiki, logi z consoli, źródło strony, by jak najłatwiej można było przeanalizować zgłoszenie.
Jak to wygląda w Jirze.
W ramach innych wpisów pokażę Wam jak postawić sobie swoją Jirę, by móc przećwiczyć sobie poruszanie się po tej aplikacji. Ponadto będziecie mogli sprawdzać darmowe dodatki od Atlassiana.
Dobre praktyki:
Istnieje szereg dobrych praktyk, które ułatwią życie nie tylko Tobie ale i reszcie zespołu. Dodatkowo pozwolą oszczędzić Twój czas:
Jedno zgłoszenie – jeden błąd – warto by nie pisać o dziesięciu wątkach w jednym zgłoszeniu, tylko konkretnie o jednej funkcjonalności.
Przeczytaj zgłoszenie po napisaniu – sprawdź czy błąd który zgłosiłeś, jest opisany poprawnie i potrafiłbyś go odtworzyć.
Sprawdź czy nie ma takiego błędu w backlogu – czasami znajdujemy błędy nie obejmujące obecnej pracy w sprincie (Scrum). Zgłaszając błąd, sprawdź czy ktoś już nie zaraportował takiego błędu.
Wykonaj retesty – po poprawieniu błędu, zrób retesty czy wszystko działa jak powinno. Sprawdź też w miarę możliwości czy nie pojawiły się na skutek tej poprawki inne nowe defekty.
Stwórz szablon – stwórz szablon do rejestrowania błędów by zachować przejrzystość dla zespołu a także by nie zapomnieć o którymś z elementów.
Podsumowanie.
Zgłaszanie błędu wydaje się czynnością trywialną i wtórną. Należy jednak pamiętać by przekazywać jak najwięcej informacji by zaoszczędzić czas programistów, jak i swój. Pomyśl – zgłosisz 10-20 błędów, jednak ich opis będzie niezrozumiały. W tym momencie w trakcie jednego dnia musisz 10-20 razy oderwać się od pracy by wytłumaczyć współpracownikom co miałeś na myśli.
