Dlaczego zwykłe „nie działa” nie wystarcza

Każdy, kto kiedykolwiek pracował w branży IT, zetknął się z problemami komunikacyjnymi na linii programista-tester, opcjonalnie: inna osoba, zajmująca się sprawdzaniem, czy zadanie jest poprawnie wykonane. Rozmawiając z programistami, możesz poznać wiele anegdot odnośnie tego, jakiego rodzaju zgłoszenia zwrotne dostawali. Będąc testerem w drupalowej agencji, widzę drugą stronę medalu, ale rozumiem programistów Drupala. Zwracając zadanie, czasem mam ochotę napisać po prostu: „Nie działa”. Jednak sytuacje, w których wszystko nie działa, nie zdarzają się praktycznie wcale. Należy wierzyć, że jeżeli programista zdecydował się przekazać swój kod do testów, to jest on przekonany, że u niego działa i sprawdził chociaż podstawowe ścieżki na swoim środowisku. Dlatego też powinniśmy postarać się przekazać programiście jak najwięcej informacji odnośnie do błędu, który udało nam się znaleźć.

„Nie działa”

Zgłoszenie, które nie zawiera wystarczających informacji, traci swój sens, ponieważ uniemożliwia odtworzenie błędu przez programistę i tym samym nie daje możliwości szybkiego rozpoczęcia naprawiania defektu. Zasadniczo polecam kierować się zasadą, że lepiej podać trochę więcej informacji, niż podać ich za mało. Oczywiście dobrze jest zachować przy tym zdrowy rozsądek i nie przesadzać w żadną ze stron. Poniżej przedstawię kilka punktów, które warto uwzględnić podczas zgłaszania błędu:

Tytuł

Krótkie - aczkolwiek dość precyzyjne - określenie, czego błąd dotyczy, np. nieprawidłowa walidacja w formularzu kontaktowym.

ID

Numer lub ciąg znaków, pozwalający jednoznacznie określić konkretne zgłoszenie. Obecnie pracując z wykorzystaniem bugtrackerów, bardzo często nie musimy się o niego martwić, ponieważ jest generowany automatycznie do każdego zadania.

Osoba zgłaszająca

Podanie danych osoby, która znalazła błąd, daje możliwość wyjaśnienia późniejszych wątpliwości dotyczących zgłoszenia (oby było ich jak najmniej).

Wersja kodu

Określenie wersji kodu, na jakiej sprawdzane było zadanie. W zależności od polityki firmy, może to być nazwa konkretnej wersji programu, nazwa brancha lub data wykonania testu. Ważne jest, aby jednoznacznie określić, w której wersji znaleziony został błąd, ponieważ nie wszędzie może występować.

Priorytet

Priorytet najczęściej oznacza czas, w jakim dany błąd powinien zostać naprawiony. Przedstawiony jest za pomocą określonej skali np. pilny, wysoki priorytet, normalny priorytet, niski priorytet. Możemy jednak priorytet oszacować, biorąc pod uwagę kilka czynników:

• jak szybko błąd powinien zostać naprawiony,
• jak bardzo dany błąd wpływa na funkcjonowanie całego projektu,
• jak często dany błąd występuje,
• czy błąd dotyczy nowej funkcji, czy też takiej, która jest już używana przez użytkowników.  

W takim wypadku będzie to wypadkowa tych kilku czynników, podana w określonej skali np. błąd krytyczny, poważny błąd, normalny, z niskim priorytetem, sugestia zmiany. Oczywiście możemy dla każdego z tych czynników określić osobą kategorię i opisywać je w zgłoszeniu. Jest to jednak sprawa indywidualna do określenia przez każdą z firm. Ważne jest jednak to, by w jakiś sposób stopniować zgłaszane błędy.

Warunki wstępne

Jeżeli istnieją jakiekolwiek czynności, które należało wykonać przed testem lub jakiekolwiek warunki muszą być spełnione, aby możliwe było odtworzenie błędu - należy je podać, przykładowo może to być warunek założenia konta użytkownika z rolą redaktora

Środowisko testowe

Zdarzają się sytuacje, w których dany błąd występuje tylko w określonej konfiguracji sprzętowej. Dlatego podczas zgłaszania błędu, należy podać możliwie jak najwięcej szczegółów np. na jakim urządzeniu błąd został znaleziony, na jakim systemie operacyjnym, na jakiej przeglądarce, czy zainstalowane jest jakieś oprogramowanie, które może wpływać na działanie programu, jaka jest rozdzielczość mojego monitora, itp.

Opis błędu/kroki do odtworzenia błędu

Oczywiście sam tytuł błędu nie wystarcza - należy również w jasny i możliwie jak najbardziej precyzyjny sposób określić, w czym tkwi problem. Możemy tu zacząć od krótkiego wprowadzenia, wyjaśniającego na czym błąd polega, jednak najważniejszą sprawą jest dobre rozpisanie kroków, które doprowadziły na`s do wystąpienia błędu. Nie należy tu używać zwrotów typu: „przeszedłem do innego okna” lub „wprowadziłem jakieś dane”, należy konkretnie określić gdzie klikamy i co wpisujemy, ponieważ to właśnie wpisanie określonych danych, może spowodować wystąpienie błędu. Jeżeli testujemy aplikację webową powinniśmy tu podać adresy URL stron, które doprowadziły nas do wykrycia błędu.

Aktualny rezultat

Kiedy już wykonałeś wszystkie kroki, które doprowadziły Cię do błędu - to, co wówczas się wydarzyło, również wymaga rzetelnego opisania. Pamiętaj żeby unikać tutaj zwrotów typu: „Pokazał się komunikat z błędem”. Oczywiście, jeżeli taki komunikat się pokaże napisz o tym, ale nie zapomni dodać, co ten komunikat dokładnie zawierał, nawet jeśli Tobie to nic nie mówi, zapewne nakieruje programistę, gdzie powinien zacząć szukać problemu.

Spodziewany rezultat

Napisałeś jak do błędu doszedłeś, opisałeś to co zastałeś i mogłoby się wydawać, że już wszystko jest wiadomo i że nic więcej już nie trzeba dodawać. Faktycznie, bardzo często to wystarcza. Są jednak sytuacje, w których oczekiwania związane z problemem, nie są takie oczywiste. Dlatego pamiętaj, żeby zawsze jasno określić, czego się spodziewasz po danym zadaniu. Umożliwia to wcześniejsze wyjaśnienie ewentualnych różnic w rozumieniu działania systemu i jasno precyzuje, co należy poprawić.

„Prezentacja lepsza niż tysiąc słów...”

Bez wątpienia jedną z najlepszych metod zgłaszania błędów, jest ich bezpośrednie pokazanie programiście. Należy wówczas posadzić programistę przed naszym komputerem i pokazać krok po kroku, w którym momencie występuje błąd. Jako autor kodu, wie on najlepiej na co zwrócić uwagę, kiedy pokazuje się błąd oraz gdzie szukać dodatkowych informacji o tym co się stało. Jest on również w stanie dostrzec, co poza samym komunikatem wskazuje na to, że coś idzie nie tak jak powinno. Oczywiście nieczęsto mamy taką możliwość, by bezpośrednio prezentować błędy, ale zawsze możemy spróbować znaleźć jakąś atrakcyjną alternatywę, która - choć nie zastąpi może prezentacji bezpośredniej - na pewno ułatwi pracę. Jeżeli wiesz, że błąd, który odnalazłeś nie jest łatwy do opisania i jest dość złożony -  postaraj się nagrać swój ekran podczas testu. To z pewnością pomoże w lepszym zrozumieniu problemu. Jeśli błąd nie jest bardzo skomplikowany, postaraj się dodać chociaż screenshot z zaznaczonym miejscem, gdzie błąd występuje. Sporą część ludzkości stanowią wzrokowcy, którzy lepiej zrozumieją błąd, jeśli go zobaczą, Dzięki temu - nawet jeśli nie uda im się odtworzyć tego błędu u siebie - będą widzieli, jak on wyglądał na Twoim środowisku.

Narzędzia wspierające zgłaszanie błędów

Wszystkie powyższe elementy możemy zgłaszać na wiele różnych sposobów: słownie, w akruszku kalkulacyjnym, mailem itp. Jednak równie ważne co poprawne zgłoszenie błędu jest jego późniejsze śledzenie. Dlatego też w większości firm wykorzystuje się do tego oprogramowanie, które to wspiera. Poniżej przedstawie krótką listę rozwiązań na które warto zwrócić uwagę przy wyborze takiego narzędzia:

• Jira (rozwiązanie komercyjne),
• Bugzilla (open source),
• Mantis (open source),
• Redmine (open source),
• Tac (open source),
• Stryka (rozwiązanie komercyjne),
• LeanTesting (darmowy ale płatne komponenty),
• FogBugz (rozwiązanie komercyjne).

Podsumowanie

Na koniec podam kilka podstawowych zasad, którymi moim zdaniem, należałoby się kierować podczas zgłaszania błędów:

• pamiętaj o tym, żeby wyrażać się jasno i precyzyjnie, tak, żeby programista mógł bez problemu odtworzyć błąd,
• opisz wszystkie symptomy, świadczące o tym, że coś działa niepoprawnie, nawet jeżeli dokładnie wiesz, co jest problemem,
• zgłaszaj błędy tak szybko, jak to jest możliwe,
• zawsze próbuj powtarzać wystąpienie błędu około trzech razy i jeżeli Ci się to nie uda,
• wspomnij o tym w zgłoszeniu,
• jeśli masz możliwość pokazania błędu, to go pokaż,
• nie pomijaj w zgłoszeniu faktów, które wydają Ci się oczywiste,
• jeżeli masz taką możliwość, sprawdź czy błąd występuje tylko w danej sytuacji lub na danym sprzęcie.