Jak poprawnie zgłaszać błędy

Jak zostać testerem

Loading

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.

  1. Tytuł zgłoszenia:
    – powinien być krótki, ale treściwy i konkretny. Może zawierać słowo kluczowe obrazujące problem. 
  2. 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-LowMediumHigh-Highest
  3. 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. 
  4. Środowisko:
    Jeżeli posiadacie środowiska stagowe to koniecznie określ na którym stage testowałeś.
  5. Wersja:
    Jeżeli posiadacie wersjonowane oprogramowanie koniecznie zwróć na to uwagę przy zgłoszeniu błędu;
  6. 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. 
  7. 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. 
  8. Obecny rezultat
    Krótki opis co się dzieje obecnie po wykonaniu wskazanych wyżej kroków. 
  9. Oczekiwany Rezultat
    Wytłumaczenie jaki jest oczekiwany rezultat po przejściu kroków o których pisałeś wcześniej. 
  10. 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.