O to, jak napisać raport z testów zostałem zapytany przez jednego z moich kursantów. I właśnie w odpowiedzi na nie piszę ten wpis.
Musisz wiedzieć, że jest to pytanie, na które moim zdaniem nie ma jednoznacznej odpowiedzi. Wynika to z tego, że to jak będzie wyglądał raport z testów zależy od tego, jaki dokument zażyczy sobie klient.
Dlaczego raport z testów jest istotny?
Jednym z głównych powodów jest funkcja, którą pełni, a jest nią informowanie o wykonanych testach, a przede wszystkim o znalezionych defektach w aplikacji.
Od czego zależy zawartość raportu z testów?
To, jak napiszemy raport z testów w dużej mierze zależy od tego, jakie podejście ma nasza organizacja do tworzenia takiego dokumentu.
O tym, jak napisać oficjalny raport z testów taki zawierający wszystkie zalecane informacje możesz przeczytać na jednej ze stron testerzy.pl.
Nigdy nie zdarzyło mi się napisać raport z testów w sposób opisany przez normę ISO 29119.
Udało mi się za to z biegiem lat stworzyć szablon tego, jak raport z testów można napisać.
Pamiętaj jednak, że jest to raport zazwyczaj spełniający wymagania klientów, z którymi współpracowały firmy, dla których pracowałem. W Twoim przypadku nie musi być on taki sam.
Jak napisać raport z testów?
Raport z testów to dokument, w jego skład wchodzi informacja co i kiedy było testowane, jakie części aplikacji były testowane, co za tym idzie jakie błędy zostały znalezione. Poniżej wymieniłem wszystkie części składowe raportu wraz z objaśnieniem, co powinny zawierać.
Data raportu.
Data sporządzenia raportu.
Tytuł.
Krótki tekst, zazwyczaj mający formę. Raport z testów aplikacji X (gdzie X to nazwa aplikacji 🙂 ).
Podsumowanie wykonanych działań.
W tej części raportu z testów zawieram dwa tematy. Pierwszym z nich jest lista urządzeń i środowisk, na których odbywały się testy.
Kolejnym elementem podsumowania są wypunktowane obszary aplikacji, które zostały przetestowane, a także jakie testy wykonałem. Często dodaję tutaj średni czas, jaki poświęciłem na testy danego obszaru.
Przykład:
- Kreator wnętrz architektonicznych. 2h testy funkcjonalne oraz retesty poprawionych defektów.
- Search (to taka szukajka na większości stron dostępna). Poświęciłem 0,5h na testy funkcjonalne.
- Koszyk. 4h, Testy wartości brzegowych, testy walidacji.
- Cała aplikacja A/B testy 2h.
Podsumowanie wszystkich defektów.
Tutaj drobna rada listę błędów znalezionych warto rozbić na grupy.
- Poprawione i zretestowane
- Prosta sprawa, znaleźliśmy defekt, który został poprawiony, zanim zakończyliśmy nasze testy. Potwierdziliśmy, że poprawka była skuteczna. Błąd nie występuje więcej w aplikacji.
- Do poprawienia
- To są defekty, które nasz zespół nie zdążył naprawić przed wysłaniem raportu z testów.
- Ryzykowne poprawki
- Takie, które są ryzykowne do poprawienia w danym momencie.
Temat wręcz na inny artykuł, ale spróbujmy w skrócie.
Czasami jest tak, że na podstawie danych historycznych wiemy, że dany obszar aplikacji delikatnie mówiąc jest kiepsko napisany. Jeżeli więc np. znajdziemy defekt, który nie jest krytyczny, to czasami kierownik projektu może podjąć decyzję o wdrożeniu takiej aplikacji mimo takiego babola czyhającego na użytkowników. Oczywiście po wdrożeniu w zależności od ważności rozważamy jego naprawę. Może ona nastąpić szybciej/wolniej lub czasem wcale, ponieważ koszt naprawy jest odwrotnie proporcjonalny do korzyści z tejże naprawy. Przykładowo poważny błąd funkcjonalności, która zgodnie z logami została użyta raz na przestrzeni roku.
- Takie, które są ryzykowne do poprawienia w danym momencie.
Listę błędów tworzę poprzez wylistowanie wszystkich tytułów błędów wraz ze zrzutami załączonymi do nich. Jeśli klient ma dostęp do Jiry, dodaję również link do błędu.
Podsumowanie kryteriów zakończenia testów.
W tej części rozwijam następujące tematy.
- Czy udało nam się zrealizować zaplanowane testy?
- Czy wystąpiły jakieś trudności? Niekoniecznie mówię tu o defektach, mogą nimi być problemy ze środowiskiem, które opóźniły albo skróciły testy. Informujemy również, czy udało nam się te problemy rozwiązać.
- Weryfikacja estymat czasu pracy.
- Ryzyka, które się zrealizowały z naszego test planu oraz czy doszło coś nowego co należy dodać do test planu.
- Informacja o możliwości weryfikacji raportu. Ja często przekazuję przypadki testowe tworzone pod testy akceptacyjne jako narzędzie, którego klient może użyć w celu tejże weryfikacji.
- Wnioski na przyszłość (pamiętajmy, aby uczyć się na błędach to jedna z ważniejszych czynności w IT).
Pobierz przykładowy raport z testów
Poniżej znajdziesz linki do plików w formacie OpenOffice, Microsoft Word oraz pliku .xls. Pierwsze dwa stworzone zostały na bazie tego artykułu, są one przykładem/szablonem raportu z testów, który tak jak wcześniej wspomniałem najczęściej spełnia wymagania klientów.
Plik w formacie .xls wygenerowałem z TestLinka po to byś mógł zobaczyć (o ile jesteś ciekawy) jak wygląda taki raport z testów.
Czy raport z testów oddawany jest każdorazowo po wykonaniu testów?
Nie zawsze zdaję raport z każdych wykonanych testów, tak jak wspomniałem zarówno forma raportu, jak i jego częstotliwość zależą od klienta i jego potrzeb.
W związku z tym może być tak, że raport oddaję dopiero po zakończeniu finalnych testów na środowisku preprodukcyjnym. Dlatego nie uwzględnię w nim testów, które wykonaliśmy na innych środowiskach. Ani błędów znalezionych we wcześniejszych testach.
Na zakończenie chcę ci przypomnieć, że raport z testów nie zawsze będzie tak wyglądał. W przypadku projektów, gdzie formalności będą bardziej wymagane może się zdarzyć, że napiszesz raport z testów bardzo dokładny, zgodnie z artykułem, do którego link umieściłem wcześniej. W innym projekcie może być z kolei tak, że raport z testów będzie miał charakter nieformalny i zawierać będzie tylko kluczowe informacje dla klienta.
O tym, jakie dane są kluczowe dla niego, decyduje sam klient.
Zdarzało się również, że sam raport z testów, jaki miałem wystawić był generowany z TestLinka, ponieważ takie były wymagania klienta.
Nie ma zatem jednoznacznej odpowiedzi na pytanie jak napisać raport z testów, na szczęście z biegiem czasu istnieje możliwość wypracowania w miarę uniwersalnego szablonu.
Czy wiesz, że najlepiej mi się pisze, gdy wiem, że na tekst jest zapotrzebowanie?
Dlatego, jeśli masz jakiś temat dotyczący testowania, który chciałbyś, abym uwzględnił w artykule, napisz do mnie. Dla przykładu jeden z moich kursantów poprosił mnie o napisanie artykułu o tym, jak napisać raport z testów. I jak widzisz wpis powstał.
Inny wpis, który powstał na prośbę czytelnika dotyczy pisania przypadków testowych.
