Podziel się tym wpisem!

jak napisać raport z testów
Jak napisać raport z testów

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:

  1. Kreator wnętrz architektonicznych. 2h testy funkcjonalne oraz retesty poprawionych defektów.
  2. Search (to taka szukajka na większości stron dostępna). Poświęciłem 0,5h na testy funkcjonalne.
  3. Koszyk. 4h, Testy wartości brzegowych, testy walidacji.
  4. 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.

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.

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

Znalazłeś błąd na tej stronie? Zgłoś mi go.
Formularz zgłoszenia błędu

Jeśli znalazłeś błąd w tekście lub na stronie to proszę, zgłoś mi go. Większość pól tego formularza nie jest wymagana. Jeśli chcesz zgłosić błąd tak, jak powinno się to zrobić, wypełnij je wszystkie.

W formularzu brakuje pola „dodaj załącznik”, ponieważ użycie tej formatki jest płatne. Jeśli jednak chcesz wysłać mi załącznik, prześlij go na e-mail waldemar.szafraniec.szkolenia@gmail.com, w tytule wiadomości napisz, że jest to załącznik do zgłoszenia błędu.

Podany e-mail będzie wykorzystany tylko w celu obsługi tego zgłoszenia - zostaniesz poinformowany, gdy błąd zostanie poprawiony. Podanie e-mail nie jest równoznaczne z zapisem na newsletter.
Tytuł powinien w sposób jasny i czytelny mówić co nie działa na stronie.
Ile prób odtworzenia błędu udaje się odtworzyć.
Dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć.

Podziel się tym wpisem!

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz