Testerzy(-rki) to nie są mili ludzie. O nie. Porównajmy takiego testera z deweloperem. Ten drugi kmini sobie zadanie, pomyśli, wymyśli, nagłówkuje się przy tym, a w końcu napisze i z dumą i uśmiechem może ogłosić: „Ej, słuchajcie, napisałem taki fajny ficzer”. Szef klaszcze, klienci się cieszą, a tester to ten wredny ludź z tyłu sali o aparycji Grincha, który zaciera właśnie ręce z miną Scrooge’a liczącego procent od pożyczki i ma na twarzy wypisane: „Fajny ficzer mówisz? I może jeszcze działa, co?”. A potem robi testy i z miną aniołka podnosi rękę i głosem niewiniątka zgłasza:„Ja najmocniej przepraszam, możliwe, że czegoś nie zrozumiałem (ta, akurat, nie zrozumiał), ale tu chyba mamy taki drobny defekcik”. Podstępna żmija.
No dobra, żartuję. Wiadomo, że testerzy(-rki) to najsympatyczniejsi ludzie na świecie. Jak więc wszystkim ułatwić pracę i napisać porządny donos… tfu… porządne zgłoszenie błędu?
Po pierwsze: tytuł, który w zasadzie mówi wszystko. Ale nie jest za długi. Na przykład:
„[Test1] [Chrome] Dodanie nowego produktu do listy ulubionych, a następnie do koszyka kończy się błędem”
W dwóch z trzech projektów spotkałam się z tagami, które od razu sprzedawały cenne informacje takie jak środowisko, na którym błąd został znaleziony, czy przeglądarka. Tytuł musi być akuratny.
„Błąd w trakcie dodawania produktu do koszyka” – niby jest ok, ale trochę jakby za ogólny.
„Błąd AABB448596JKIU (tu cała treść tego błędu) w czasie dodawania do koszyka pięciu kostek masła poprzedzonych dodaniem paczki gumek i dwóch opakowań bitej śmietany na przeglądarce Chrom w wersji 106.0.5249.119” – to już za dużo. Na szczegóły jest miejsce gdzie indziej.
Po drugie: wszystkie informacje dotyczące środowiska i sprzętu, jeśli to ma znaczenie. Jeśli testujecie mobilki, wersja Androida czy iOS-a będzie miała dla dewelopera istotna. Jeśli defekt pojawia się tylko na komórce danego producenta, to też jest ważne. Jeśli błąd jest w przeglądarce, to trzeba napisać w jakiej. Jeśli macie kilka środowisk – konieczne jest oznaczenie, na którym błąd został znaleziony. Jeśli wersjonujecie buildy oprogramowania, podajcie numer wersji.
Po trzecie: kroki reprodukcji.
Systemy informatyczne są piekielnie skomplikowane i serio – chyba nikt nie wie do końca, jak to ustrojstwo działa. Dodajecie do koszyczka pralkę, suszarkę i magnetofon i wszystko działa, a słuchawki dostajecie za darmo. Ale jak dodacie magnetofon, suszarkę i pralkę to dupa, nie ma słuchawek i niech mi ktoś powie, dlaczego. Dlatego tak ważne jest, żeby w krokach reprodukcji podać dokładnie i szczegółowo wszystkie ruchy, po których wystąpił błąd. Może być tak, że da się usterkę wywołać krótszą ścieżką i wtedy to właśnie ją podajemy. Ale bywa i tak, że guzik ON/OFF zawiesza się po każdych 2 tysiącach kliknięć i niestety nie da się tego skrócić do 200.
Po czwarte: Wyniki – oczekiwany i aktualny
Czyli piszecie: Oczekiwany: Produkt jest w koszyku. Aktualny: Produktu nie ma w koszyku. Chyba nie muszę wyjaśniać po co 🙂
Po piąte: Wszystkie dodatkowe informacje, które mogą się przydać w analizie błędu.
Może był podobny błąd i został rozwiązany – podajcie link do jego zgłoszenia. Linki do dokumentacji, historyjek użytkownika czy innej formy wymagań – każda dodatkowa informacja pomoże szybciej znaleźć przyczynę błędu.
Po szóste: logi, screeny.
Oczywiście zależy, co testujecie. W automatach zwykle mamy logi w kilku różnych wersjach. Testerzy manualni z kolei potrafią pięknie dokumentować testy screenami lub nagraniami. Załączniki mogą też zawierać poprawne ilustracje, np. z poprzednich egzekucji testu, dzięki czemu można porównać zachowanie prawidłowe z nieprawidłowym.
Po siódme (opcjonalnie): osobę do kontaktu.
Szczególnie w dużych zespołach dobrze jest wskazać, z kim się w sprawie defektu kontaktować. Taka Jira na przykład ma pole do oznaczenia wystawiającego, ale przecież to niekoniecznie on jest osobą, która na dany temat wie najwięcej.
To, co powyżej, powinno być przyzwoitym minimum. Wiadomo, że inaczej będzie wyglądało zgłoszenie błędu w oprogramowaniu pralki, inaczej w sklepie z gadżetami dla pupili, a jeszcze inaczej w aplikacji do projektowania wzorów szydełkowych. Grunt, żeby nasze zgłoszenie, było solidnie poparte faktami (w przeciwieństwie do donosu).