Zgłaszanie błędów – wskazówki jak robić to dobrze

Zastanawialiście się kiedykolwiek czym jest zgłoszenie błędu? W mojej głowie widnieje on jako raport ze śledztwa. W kodzie znajduje się błąd, a Ty podczas rutynowej kontroli odkryłeś jego kryjówkę. Teraz Sherlocku musisz wytłumaczyć Watsonowi kto i dlaczego morduje funkcjonalności Waszego produktu.

Do-it-sherlock-1024x595

Pytanie pierwsze: Kim jest odbiorca zgłoszenia i dlaczego chce mieć informacje o błędach?

Najbardziej oczywistym odbiorcą zgłoszenia jest developer. Oczekuje on od takiego zgłoszenia maksimum informacji, które pozwolą mu zlokalizować problem w kodzie i go naprawić. To jednak nie koniec. Odbiorcami jesteśmy również my – testerzy. Zgłoszenie błędu jest sposobem dokumentacji naszej pracy. Umożliwia on również replikację błędu – zarówno przez nas samych jak i przez innych testerów, którym przyjdzie pracować z naszym produktem. Mniej oczywistymi odbiorcami są również interesariusze oraz właściciel produktu. Od zgłoszeń oczekują oni informacji o istniejących błędach w produkcie, ich statusie oraz lokalizacji.

Mając już informacje o tym dla kogo piszemy zgłoszenia błędów możemy przystąpić do kolejnego kroku.

Pytanie drugie: Jak w ogóle zgłosić błąd?

Metod zgłoszenia błędu jest bardzo dużo. Może być to proste jak konstrukcja cepa – wysłanie e-maila do odpowiedniej grupy osób. W ten sposób najczęściej przyjmuje się zgłoszenia od użytkowników. Ma to jednak swoją wadę – ciężko takimi zgłoszeniami zarządzać. Taki raport nie posiada swojego unikalnego numeru, nie wiadomo kto zajmuje się rozwiązaniem danego problemu a co gorsza – może zginąć w nawale innych informacji.

Inną metodą dostępną przy bliskiej współpracy z developerem jest napisanie mu wiadomości. Również nie do końca efektywne. Wiadomość może zostać przeczytana i zapomniana, takie zgłoszenie nie posiada unikalnego numery po którym można by było się do niego odnieść, a co gorsza wtedy tylko tester i ten jeden developer wiedzą o tym, że taki błąd istnieje. A co z interesariuszami i właścicielem produktu?

Dlatego właśnie istnieją bugtrackery. Są to środowiska mające możliwość zbierania, katalogowania i zarządzania zgłaszanymi błędami. Istnieją jako odrębne byty służące tylko do raportów błędów, jak i stanowią czasem element całego systemu zarządzania projektem. Do najpopularniejszych z nich należą:

BugTracking

Pytanie trzecie: Jak powinno wyglądać zgłoszenie, by spełniało potrzeby wszystkich odbiorców?

Niezależnie od wybranej metody zgłoszenia błędu stajemy w końcu przed dylematem jak zrobić to dobrze. Do tego potrzebne są następujące elementy:

  • Unikalny numer
  • Tytuł
  • Środowisko
  • Autor
  • Priorytet
  • Miejsce wystąpienia i ścieżka odtworzenia
  • Oraz dodatkowe rzeczy jak: URL, screen, logi, oczekiwany rezultat, uwagi testera

Unikalny numer
jest potrzebny do komunikacji. Dużo łatwiej i szybciej wkleić rozmówcy numer błędu, niż opisywać za każdym razem na czym on polega. Unikamy też w ten sposób nieporozumień: przykładowo komunikat “Wrzuciłem poprawkę do błędu wyszukiwania w grupach” jest dla mnie niezwykle enigmatyczny, bo może dotyczyć grup kontaktów, grup dyskusyjnych lub grup na forum. Dużo bardziej wolę krótki komunikat “Błąd #135671 gotowy do testów”.
Tytuł ma za zadanie już na pierwszy rzut oka powiedzieć wszystkim gdzie w naszym produkcie jest błąd i na czym on polega. Przykładowo ja w tytule zaczynam od umieszczenia lokalizacji (modułu) w nawiasach kwadratowych na przykład [Galeria] czy [Forum]. Gdy uznam, że stwierdzenie modułu nie wystarczy dodaję kolejny nawias uszczegóławiający miejsce na przykład [Wyszukiwarka][Grupy]. W następnej kolejności opisuję krótko naturę błędu. Dobrze opisany tytuł, rozumiany przez cały zespół tak samo, to połowa sukcesu.
Ważne jest opisanie na jakim środowisku (testowym, produkcyjnym, jaki system, jaka przeglądarka i inne) występuje błąd. Dobrą praktyką jest również opisanie wersji kodów, z którymi błąd został wprowadzony. Sama znajdując błąd na produkcji mam tendencję do cofania wersji kodów na środowisku testerskim by odszukać ten moment – pozwala to na porównanie wersji i możliwie szybsze odnalezienie błędu.

Autor zgłoszenia zwykle jest dopisywany automatycznie. Warto jednak pamiętać o zawarciu tej informacji na przykład, gdy zgłoszenie pochodzi od użytkownika.

 

Kolejną ważną informacją jest priorytet. Niezależnie od tego czy to będzie priorytet oznaczany kolorem, tagiem, słownie czy pozycją w narzędziu – ważne jest by był. Każdy z naszych odbiorców musi wiedzieć jak bardzo krytyczny dla naszego produktu jest znaleziony błąd – i na tej podstawie podejmować działania.

 

I tak oto dotarliśmy do najważniejszej częścią zgłoszenia – opisu błędu. Musi się znaleźć ścieżka odtworzenia błędu. Zwykle są to kroki, jakie należy wykonać by dojść do momentu niepoprawnego zachowania się produktu. Dodatkowo informacje w tytule na pewno też nie wystarczą by dokładnie zlokalizować błąd, dlatego w opisie warto opisać dokładniej miejsce występowania błędu.

 

Ludzie z natury są jednak leniwi, dlatego doskonałym sposobem w miarę możliwości jest dołączenie do słownego opisu link URL.

 

Nie zawsze jednak link prowadzi bezpośrednio do samego błędu – tu wspaniałym rozwiązaniem okazuje się zrzut ekranu. Już sam zrzut ekrany oprócz lokalizacji błędu może dostarczyć nam masę informacji na temat środowiska błędu – jaka została użyta przeglądarka, czy jest uruchomiony tryb incognito, pod jakim linkiem URL, czy w konsoli znajdują się jakieś informacje i inne.

 

To samo dotyczy logów. Mam nadzieję, że podczas testowania macie dostęp do nich, a jeśli nie – to czas najwyższy się o to postarać. Wklejenie do zgłoszenia informacji z logów z momentu wystąpienia błędu to najbliżej jak możemy być do dokładnego pokazania palcem w kodzie co jest nie tak.

 

Warto również zamieścić w opisie jakiego rezultatu oczekiwaliśmy, że uznajemy aktualne zachowanie produktu za błąd. Przykładowo błędem jest, że jeden z przycisków na stronie nie działa i nic się nie dzieje po jego kliknięciu. Developer może nie wiedzieć co dokładnie powinno się stać po kliknięciu w ten przycisk.

 

Nie bójmy się również dołączyć swoje uwagi. Pamiętasz, że taki błąd już występował? Dołącz tą informację.

Advertisements

One thought on “Zgłaszanie błędów – wskazówki jak robić to dobrze

  1. Pingback: Rekrutacja w IT okiem małego żuczka | World & Testing

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s