Dzisiaj napiszę kilka słów o niezbędnym elemencie w każdym procesie testowym – mowa oczywiście o tytułowym – Raporcie z Testów. Na początek, krótka regułka określająca, czym tak naprawdę jest Raport z Testów:

O jakich czynnościach testowych traktuje powyższa definicja? Oczywiście chodzi o aktywności testowe całego procesu testowego, w którym bierzemy udział. Zatem raport to po prostu pewna próba oceny wszystkich czynności testowych, którymi pokryliśmy testowaną aplikację. Standardowy proces testowy składa się z poniższych faz:

• Planowanie testów
• Analiza testów
• Projektowanie testów
• Implementacja testów
• Wykonywanie testów
• Czynności zamykające testy

Ocena powinna dotyczyć wszystkich przebytych faz procesu testowego. Dobry raport z testów powinien zawierać informacje o wszystkich działaniach testowych, jakie zostały wykonane, np. uruchomione przypadki testowe, wykryte defekty, metryki, statystyki np. udanych / nieudanych przypadków testowych.
Dzięki poprawnie przygotowanemu raportowi z testów i ocenie poszczególnych artefaktów testowych – interesariusze mogą podjąć świadomą decyzję o dalszej przyszłości oprogramowania.

Dlaczego powinniśmy sporządzić raport z testów?

1. Jest to idealna forma podsumowania procesu testowego
2. Raport z testów często jest wymaganym przez klienta dokumentem, na podstawie którego podejmuje się decyzje o dalszej fazie rozwoju oprogramowania
3. Tego typu dokumenty przydają się również zespołowi developerskiemu, gdyż można wyciągać wnioski o słabych punktach oprogramowania i wdrażać procesy naprawcze

Przykładowy raport z testów

Raporty z testów mogą być tworzone ręcznie, ale również automatycznie – jak w przypadku testów automatycznych, gdzie odpowiednie biblioteki, usługi, rozwiązania zbierają wyniki testów i tworzą precyzyjne podsumowania w formie plików np. html, czy pdf. Poniżej prezentuję raport z przebiegu procesu automatyzacji testów, który został wygenerowany automatycznie przez bibliotekę Extent Reports oraz przez narzędzie CI – Jenkins. Jak możecie poniżej zobaczyć, jest to doskonałe podsumowanie wykonania wielu przypadków testowych.

Kto konsumuje Raportu Testów?

Jeśli chcemy stworzyć dobry i wartościowy raport z testów, to przede wszystkim musimy sobie odpowiedzieć na pytanie: Kto będzie odbiorcą raportu? To pytanie jest istotne, gdyż grup odbiorców raportu może być kilka i w takim przypadku, każda z grup może oczekiwać nieco innych danych i informacji. Zatem możemy już teraz wysunąć wniosek, że nie ma jednego, dobrego, standardowego wzoru raport testów. Najlepszy raport z testów to taki, który jest elastyczny i daje się łatwo modyfikować względem potrzeb grup odbiorców. A jakie grupy odbiorców wyróżniamy?

• Osoby techniczne (np. Kierownik testów, kierownik działu testowego)
• Osoby biznesowe (Product owner, kierownik projektu, sponsor)

Jasne jest, że dla osób technicznych, raport powinien zawierać informacje nieco bardziej techniczne, czyli takie, które wprowadzają jakąś wartość dodaną do pracy tychże osób. A więc możemy w tym przypadku umieszczać takie informacje jak: logi z konsoli, opis metod, funkcji, parametry testów, środowiska, wersji, infrastruktury itp.
Dla osób biznesowych takie informacje nie są dalece istotne dlatego, dla niech powinniśmy wyświetlać opisowe informacje w formie np. diagramów czy wykresów i przedstawiać takie informacje jak: liczba znalezionych błędów, priorytety błędów itp. Osoby biznesowe oczekują konkretnej informacji o stanie aplikacji, a nie szczegółów technicznych, gdyż i tak nie posiadają takiej wiedzy, aby je właściwie interpretować.

Cechy dobrego raportu z testów

Kieruj się trzema poniższymi cechami, aby stworzyć dobry raport podsumowujący proces testowy.
Raport z testów powinien być:

1. Szczegółowy
Wszystkie informacje w raporcie powinny być jasne, konkretne i zrozumiałe. Oczywiście należy unikać obszernych opisów i nie należy tworzyć rozbudowanych esejów, a jedynie zawierać niezbędne i oczekiwane przez klientów informacje.
Dlatego wygląd a w szczególności zawartość raportu należy na samym początku skonsultować z potencjalnymi grupami konsumentów tychże dokumentów.

2. Czytelny
Raport powinien być tak skonstruowany, aby był przejrzysty, a zawarte w nim informacje czytelne i jednoznaczne. W celu lepszej czytelności i łatwości odbioru dobrym pomysłem jest stosowanie różnego rodzaju zestawień, tabel, wykresów, diagramów itp. Często jeden wykres przedstawia więcej niż tysiąc słów😊

3. Elastyczny
Elastyczności w kontekście raportu, należy rozpatrywać jako możliwość szybkiego dostosowywania do nowych danych, informacji, a także grup odbiorców.

Co powinien zawierać dobry raport z testów?

Jak wspomniałem już wcześniej, nie ma jednego, właściwego wzoru raportu z testów, gdyż każdy proces testowy jest inny oraz inne są wymagania i oczekiwania naszych klientów. Niemniej jednak postaram się niżej wyszczególnić najważniejsze elementy, które powinien zawierać poprawnie napisany raport testowy.
Dobry raport z testów powinien zawiera następujące sekcje:

1. Cel dokumentu
Powinniśmy zacząć od określenia, jaki jest faktyczny cel dokumentu. Jak już wiemy, celem dokumentu jest podsumowanie procesu testowego. Warto tu konkretnie określić projekt oraz ramy czasowe projektu.

2. Podsumowanie czynności testowych
Tutaj konkretnie wypisujemy jakie czynności testowe zostały przeprowadzone, np. testy manualne, testy automatyczne, testy wydajnościowe, testy bezpieczeństwa itp. Możemy tutaj załączyć listę wykonanych scenariuszy testowych, historyjek użytkownika itp. Jeśli określiliśmy sobie w Planie Testów, jakie konkretnie testy powinny zostać wykonane, to jest do dobre miejsce na to, aby wypisać również testy, które nie zostały przeprowadzone i wyjaśnić przyczynę ich niewykonania bądź niepowodzenia.

3 Analiza statusów testów
W tej sekcji możemy posłużyć się wszelkimi metrykami, grafami, wykresami, tabelami, aby zobrazować faktyczny stan testowanej aplikacji. Wobec tego możemy umieścić tutaj informacje o liczbie wszystkich znalezionych błędów, możemy tę liczbę rozbić na ich wagę (np. krytyczny, wysoki, średni, niski), liczbę uruchomianych testów, liczbę przypadków testowych, kroków testowych, czasów wykonań itp. Im dokładniejsze metryki, tym więcej informacji możemy z nich wycisnąć lub wydedukować.

4. Znalezione błędy
Warto w raporcie testów znaleźć miejsce na sekcję, w której wypiszemy wykryte błędy, które z różnych przyczyn nie zostały naprawione. Nie wszystkie błędy muszą zostać naprawione od razu, gdyż część z nich może np. zostać zaakceptowana przez klienta. Tym samym klient bierze na siebie ryzyka związane z danym defektem, czy niepoprawnym działaniem. Naprawę takich błędów można przesuwać w czasie np. na kolejne sprinty, ale to już często decyzja klienta, który np. nie chce marnować czasu na poprawę błędu, gdyż woli skupić się na rozwoju nowych funkcjonalności, czy po prostu uważa, że w tej chwili ten błąd nie ma dla biznesu wielkiego znaczenia. Warto w sposób jasny wypisać sobie tutaj listę takich błędów, będzie to na pewno korzystne dla nas (mamy potwierdzenie tego, że klient wie o danym błędzie), jak i dla klienta (jako przypomnienie o istniejących problemach czekających na decyzję o ich naprawie).

5. Ryzyka
Bardzo ważny punkt w kontekście całego projektu. W tym miejscu warto wypisać wszystkie nam znane bądź potencjalnie przewidywanie ryzyka, które mogą mieć realny wpływ na dalszą fazę rozwoju aplikacji. Jakie mogą być to ryzyka? Jednym z częstych ryzyk jest brak rzeczywistych danych testowych, czyli takich, które wiernie symulują zachowanie danych produkcyjnych. Zdarza się często, że do testów korzystamy z danych testowych, które są niepełne, niedopracowane, znacznie różniące się od danych produkcyjnych. Taki brak zgodności danych testowych z danymi produkcyjnymi niesie za sobą ryzyko, że nie do końca przetestowaliśmy tak aplikację, jak będą z niej korzystać klienci. To ryzyko jest spore i bardzo często podnoszone w projektach. Kolejnym bardzo podobnym ryzykiem może być, brak środowiska testowego zgodnego ze środowiskiem produkcyjnym. Tutaj sytuacja jest analogiczna: testujemy oprogramowanie na środowisku testowym, które z różnych powodów nie jest zbliżone do środowiska produkcyjnego. Mogą się wiec zdarzyć sytuacje, że błędy, które pojawią się na produkcji, nigdy wcześniej nie mogły być znalezione (na środowisku testowym), gdyż wynikają z konfiguracji środowiska, infrastruktury produkcyjnej.

6. Nasze rekomendacje
Kończącym punktem raportów testów, powinna być sekcja, w której spiszemy nasze rekomendacje co do dalszych działań. Zalecenia te powinniśmy wysunąć z całego procesu testowego i powyższego raportu. Jeśli np. widzimy, że nie zostały wykonane testy wydajnościowe (bo klient nie chciał tracić czasu, czy budżetu na ich wykonanie) to warto taką rekomendację dodatkowych testów załączyć. Być może mamy świadomość, że aplikacja wykorzystuje jakieś stare czy nieaktualne sterowniki, komponenty – wówczas również warto wszelkie spostrzeżenia jasno wypisać. Oczywiście klient będzie decydował o tym, czy zastosuje się do zaleceń, ale dla nas powinno być ważne tylko to, że dołożyliśmy wszelkich starań do tego, aby według naszej najlepszej wiedzy pomoc klientowi w realizacji jego celu, jakim jest poprawnie działająca aplikacja.

Autor: Tomasz Stelmach