Redakcja
Raporty z testowania mogą mieć różne formy, od nieformalnych podsumowań tego, co tester wykonał danego dnia, po formalne podsumowanie pewnego etapu testowania. Mogą być one mailem, dokumentem albo wpisem w narzędziu. W każdym przypadku obowiązuje jednak kilka prostych zasad, które poprawiają czytelność raportu i uczynią go łatwiejszym do przyjęcia.
1. Nie pomijaj w raporcie ważnych elementów organizacyjnych.
Każdy, nawet najmniejszy raport, powinien mieć taką strukturę aby był gotowy do przekazania klientowi czy też projektowi. Musi więc zawierać informacje co był testowane, kiedy było testowane i przez kogo.
2. Uatrakcyjnij raport.
Raporty tekstowe czyta się ciężko, trzeba próbować uatrakcyjniać je wizualnie np. przez formę tabelaryczną, dodawanie zrzutów ekranu z opisem tekstowym, strzałką wskazującą dany element i tym podobnymi.
3. Uporządkuj raport.
Raport powinien mieć strukturę. Pomagają w tym nagłówki i sekcje, które pokazują jak zaadresowane są poszczególne jego aspekty.
4. Dbaj o jakość języka i wystrzegaj się błędów.
Wszyscy mamy z tym problem, ale w pracy jest ważne aby nie dać się „przyłapać” na prostych błędach. Szczególnie na błędach, których nie wychwyci autokorekta np. „po przez” => „poprzez” czy „było by” => „byłoby”. Warto powalczyć o dobrą składnię, która często znaczy „pisz prosto”. Unikaj długich zdań, zdań wielokrotnie złożonych czy nawiasów większych niż treść zdania. W raportach należy unikać również kolokwializmów oraz sformułowań potocznych. Ich pojawienie się może obniżać ocenę profesjonalizmu autora.
5. Pozbaw swój raport emocji.
Jest to szczególnie trudne np. w przypadku testowania użyteczności, które jest mocno subiektywne. Stwierdzenia typu „nie podoba mi się” mogą być postrzegane jako kontrowersyjne i konfrontacyjne. Pamiętaj proszę, że nie tester zamawia dane oprogramowanie. Programista może łatwo powiedzieć – „ma się podobać klientowi”. Lepszą formą jest próba wejścia w buty użytkownika i wypowiadania się w jego imieniu np. „użytkownikom może nie podobać się” lub „użytkownicy mogą uznać tą rzecz za dokuczliwą”. Nie zmienia to faktu, że jest to ciągle pewna opinia, ale jej forma zachęca do rozważenia czego potrzebuje nasz końcowy użytkownik.
6. Nie raportuj wyników pracy analizatora bez dodatkowego przepracowania jego wyników.
W pracy często posługujemy się różnego rodzaju analizatorami, które zwracają nam informacje na wysokim poziomie ogólności np. "wydajność aplikacji to 20/100", "aplikacja jest niebezpieczna", "użyteczność strony jest na poziomie - słaba" i tym podobne.
Sucha informacja z takiego narzędzia nie jest podstawą do stworzenia raportu. Kroki reprodukcji nie mogą się sprowadzać do „uruchom analizator i sprawdź negatywny wynik”. Jest to tylko wyjście do poważniejszej analizy, które może nam pokazać prawdziwe problemy. Przykładowo czas ładowania się strony może zależeć od wielu czynników jak np. brak cache-owania czy brak kompresji obrazów. Dobry raport problemu powinien zawierać szczegółową analizę wyników pracy analizatora.
7. Mniej znaczy więcej.
Powielanie zbędnych informacji w raporcie często zamazuje jego obraz. Dodanie nadmiarowych elementów lub długich opisów niewiele wnosi. Co więcej, może generować dodatkowe pytania. Stosowanie metody copy-paste zawsze będzie generowało dużo treści. Warto jednak zadać sobie pytanie czy jest to treść wartościowa? Raporty muszą być tworzone inteligentnie, a to znaczy, że nie mogą być ani zbyt długie, ani zbyt krótkie. Szukamy w nich skrótów i uproszczeń. Często lepsza będzie jedna rozbudowana tabelka niż 10, do których trzeba przescrollować aby zestawić sobie dane.
W raportach unikamy jak ognia rozbudowanych historii, narracji i kwiecistych opisów. Język raportu musi być prosty, wręcz żołnierski.
8. Nie kłam w raporcie.
Czasami nie wykonaliśmy całej pracy, albo nie byliśmy w stanie tego testować. Wtedy nie bójcie się napisać, że coś nie zostało sprawdzone. Zawsze to lepsze od tego, że ktoś przyłapie was na kłamstwie..
