Wykonywanie i raportowanie testów w Testlink

Jest to trzeci wpis z cyklu artykułów o TestLinku. W pierwszym artykule pisałem o instalowaniu pakietu Bitnami Testlink oraz tworzeniu pierwszego projektu w TestLink. W drugim, bardzo obszernym artykule opisałem tworzenie dokumentacji testowej, czyli specyfikacji wymagań, scenariuszy i przypadków testowych.

W tym odcinku omówię tworzenie planu testów, określanie wersji przedmiotu testów (w tym wypadku funkcjonalności rejestracji użytkownika aplikacji internetowej), dokumentowanie wykonania testów oraz raportowanie testów.

Wchodzimy na http://127.0.0.1/testlink lub localhost/testlink i logujemy się do TestLinka.

Strona startowa projektu

Zatrzymajmy się na chwilę, żeby ustalić, z czym startujemy.

Mam projekt New web app, którego nazwa wyświetla się w prawym górnym rogu ekranu startowego, czyli homepage projektu (Fig. 1). Gdybym utworzył więcej projektów, mógłbym do nich przechodzić wybierając dany projekt z listy rozwijanej.

W poprzednim odcinku utworzyliśmy sobie Specyfikację Wymagań, które możemy podejrzeć klikając przycisk z tekstem Requirement Specification po lewej stronie homepage projektu lub ikonkę w lewym górnym rogu (Fig. 1).

Specyfikacja testów

Przejdźmy teraz do specyfikacji testów. Tu również mamy dwie możliwości: boczne menu „tekstowe” lub ikonka Test Specification – zaznaczona na czerwono na Fig. 1. Klikamy i otwiera się ekran projektu, w którym mam jeden scenariusz (Test Suite) o nazwie „New user registration”. W ramach tego scenariusza stworzyłem cztery przypadki testowe, które rozpisałem na poszczególne kroki testowe.

Zaznaczając kolejne poziomy w drzewku projektu mam wgląd w scenariusz i przypadki testowe. Wejdźmy przykładowo do przypadku TC-1: New user registration with email. Sprawdzam, czy kroki testowe są prawidłowo rozpisane, jeśli tak, to przewijam ekran i zmieniam status na Final (Fig. 2).

Jednak przy Requirements widzę, że popełniłem błąd przypisując do tego przypadku wymaganie Registration with Gmail account. Klikam więc na ikonę folderu przy Requirements. W nowym oknie otwiera się ekran Assign Requirements to Test Case + nazwa przypadku (Fig. 3).

Uwaga! Jeśli przeglądarka blokuje wyskakujące okienka, należy zezwolić na ich otwieranie – zazwyczaj opcja ta jest dostępna przy pasku adresu przeglądarki.

W sekcji Assign Requirements zaznaczany „niechciane” wymaganie i klikamy przycisk Unassign. Następnie w sekcji Available Requirements zaznaczamy właściwe wymaganie i klikamy Assign. Zamykamy to okno i teraz w sekcji Requirements naszego przypadku powinno się wyświetlać właściwe wymaganie.

Możemy też kliknąć ikonę ołówka przy Requirements (Fig. 4) i wtedy otworzy się nowe okno ze szczegółami tego wymagania (Fig. 5).

U mnie – dla TC-1 będzie to wymaganie Web App Req 1.1:Registration with email. Ciekawe jest to, że w sekcji Coverage widać przypadek lub listę przypadków przypisanych do tego wymagania, czyli pokrywających to wymaganie (patrz artykuł „Jak pisać przypadki testowe”).

Również tutaj można „wyłączyć” powiązanie danego przypadku z wymaganiem klikając znajdującą się po jego lewej stronie ikonkę, którą mogę chyba opisać jako „rozłączona wtyczka” (Remove test case link).

Zarządzanie Planem Testów

Załóżmy, że nasze przypadki testowe są już zatwierdzone. Teraz zajmiemy się planem testów. Wracamy do homepage projektu (ikonka domu), gdzie klikamy Test Plan Management siedzący samotnie po prawej stronie ekranu. Niedługo przybędzie mu towarzystwo.😁

Po wejściu w Test Plan Management widzimy komunikat, że nie zdefiniowano żadnych planów testów (Fig. 6a). Klikamy oczywiście „Create”.

Otwiera się fomularz, gdzie wpisujemy nazwę i opis testu (Fig. 6b).

Tekst w dolnej części ekranu opisuje szczegółowo, co powinien zawierać plan testów. Dla celów ćwiczeniowych wpiszemy po prostu nazwę i krótki opis testowanej funkcjonalności.

Ważne jest by zaznaczyć checboxy przy Active i Public. Klikamy „Create”.

Widzimy teraz (Fig. 7) ekran Test Plan Management dla naszego projektu i tabelę, gdzie na razie mamy jeden plan, ale tu będą wyświetlane wszystkie plany tworzone w ramach tego projektu.

Uwaga! W kolumnie Test Case # oraz Build # na razie nic się nie wyświetla, bo trzeba dopiero zdefiniować wersje testowanej aplikacji i przypisać przypadki testowe do tego konkretnego planu. Widzimy, że plan testów jest aktywny i publiczny, tj. dostępny dla wszystkich potencjalnych użytkowników przypisanych do tego projektu, nie tylko dla nas jako administratora.

Klikając nazwę Test Planu w tabeli możemy wrócić do trybu edycji planu, żeby np. poprawić coś w jego opisie.

My jednak wracamy do homepage projektu (Fig. 8). Dużo nowości! Po prawej stronie przybyło sporo nowych funkcji, w lewym górnym rogu mamy więcej ikonek skrótu.

Przejdźmy teraz do Builds/Releases.

Definiowanie wersji (Builds)

Wyjaśnijmy najpierw, co to jest build. Inaczej zwana kompilacją,jest to działająca wersja oprogramowania ukończona np. w ciągu sprintu/iteracji w ramach iteracyjnego modelu wytwarzania (patrz „Iteracyjny model wytwarzania” na Testerzy.pl).

Jeśli wersja jest wypuszczana na produkcję, to jest nazywana release. Częstotliwość wersji i sposób ich numeracji różnią się w zależności od projektu i firmy. Przykładowo weźmy wersję 9.6.13, która składa się z trzech elementów:

9 oznacza wersję główną (major), 6 – wersję mniejszą (minor), a 13 to numer builda, tzw. maintenance release. Zwiększenie numeru wersji major lub minor oznacza wprowadzenie nowych funkcji lub zaktualizowanie istniejących. Natomiast zmiana numeru builda oznacza poprawkę (bugfix).

Przykłady buildów znajdziemy oczywiście w kolejnych aktualizacjach systemu Windows, zob.

https://docs.microsoft.com/en-us/windows/release-health/release-information

W TestLinku nie da się wykonać przypadków testowych, jeśli nie zdefiniujemy wcześniej builda.

Jeśli jeszcze nie kliknąłeś Builds/Releases na ekranie startowym projektu, to zrób to teraz.

Otworzy się okno  Build management – Test Plan, gdzie zaraz stworzymy Builda (Fig. 9).

Klikamy „Create” i mamy kolejny formularz do wypełnienia 😊  (Fig. 10).

Wpisujemy tytuł i opis Builda oraz zaznaczamy znowu checkboxy Active i Open.

Kategoria Open lub Closed (gdy checkbox nie zostanie zaznaczony) określa, czy dla danego builda możemy modyfikować wyniki testów.

Mamy też pola na wpisanie commit id i branch, czyli identyfikacji wersji oprogramowania w systemie kontroli wersji.

Po utworzeniu builda zobaczymy tabelę podobną do tabeli z planami testów (Fig. 11).

Stwórzmy sobie jeszcze jeden build naszego raczkującego projektu. Oczywiście przycisk „Create”! 😊

Nadam mu nazwę XYZ-1.1.2 i opis: Improved new user registration functionality.

Dodawanie przypadków do planu testów

Wracamy do homepage projektu i klikamy Add/Remove Test Cases, żeby dodać przypadki testowe do naszego planu testów. Otworzy się ekran dodawania/usuwania przypadków (Fig. 12). W sekcji Settings możemy wybrać z listy rozwijanej, którym planem chcemy się teraz zająć (jeśli utworzyliśmy więcej niż jeden plan).

Domyślnie testy będą grupowane według scenariusza (Test Suite), ale możemy też ustawić grupowanie według wymagań (Requirements) (Fig. 13).

Pozostańmy jednak przy grupowaniu według scenariusza  (Fig. 12).

Gdy w drzewie folderów klikniemy scenariusz (u mnie jest to New user registration), po prawej stronie wyświetli się lista przypadków utworzonych w ramach tego scenariusza (Fig. 14).

W górnej sekcji ekranu mamy możliwość wybrania użytkownika, któremu zostanie przydzielone wykonanie testów (Assign to user on add) oraz wybrania builda, czyli wersji aplikacji, która ma być testowana. Jeśli mamy skonfigurowany serwer SMTP, możemy ustawić wysłanie powiadomienia mailowego do testera, że ma robotę.😎

Na razie projekt ogarniamy sami, więc przypisujemy testy do siebie. Ja wybieram build XYZ-1.1.1.

Przypadki można dodać do test planu „hurtowo” przy kliknięcie przycisku Adding przy Check/uncheck all Test cases for. Oczywiście przycisk removal służy usunięciu przypadków z test planu, jeśli jest taka potrzeba. Można też kliknąć checboxy przy wybranych przypadkach testowych.

Ja zaznaczę u siebie przypadki TC-1 i TC-4, która mają status Final. Gdyby przypadek miał więcej niż jedną wersję, jest możliwość wybrania wersji.

W liście przypadków mamy również kolumnę Ważności (Importance)oraz kolejności wykonania (Execution order) wyrażonej przez rosnące liczny (10000, 10010, 10020, 100030).

Uwaga! Samo zaznaczenie przypadków nie wystarczy. Żeby dodać je do planu testów, trzeba jeszcze kliknąć przycisk Add Selected (Fig. 14).

Teraz przypadki testowe dodane do planu są podświetlone na żółto (Fig. 15). Gdyby była potrzeba usunięcia któregoś przypadku testowego, zaznaczam checkbox w przedostatniej kolumnie i klikam przycisk Add/Remove Selected.

Spójrzmy na trzecią kolumnę od końca na liście przypadków (Execution order). Jeśli zmienimy wartości przy danym przypadku i klikniemy przycisk Save order w górnej sekcji, to zmodyfikujemy kolejność wykonywania przypadków (Fig. 16). W moim przykładzie wpisałem przy TC-1 wartość 1040, wyższą od wartości 1030 przy TC-4, co znaczy, że test przypadku TC-4 zostanie wykonany jako pierwszy. Oczywiście w moim przykładzie jest to bez znaczenia i być może bez sensu, ale może zaistnieć potrzeba, by kolejność wykonania przypadków w teście była inna niż kolejność zdefiniowana w pierwotnym scenariuszu testowym.

Przyjmijmy, że taki skromny plan testów nas zadowala. Jeszcze dla większej czytelności zmienię nazwę i opis planu testów, żeby było jasne, że będę testować przypadki rejestracji użytkownika przy pomocy emaila.

Aktualizacja nazwy i opisu planu testów

W tym celu wracam na homepage projektu i klikam na Test Plan Management. W tabelce (Fig. 17) widać już, że do tego planu przypisane są dwa przypadki testowe oraz dwie wersje (Builds).

Klikam na nazwę planu New user registration w kolumnie „Name”. Otwiera się formularz (Fig. 18), gdzie zmieniam nazwę planu na Testing new user registration with email, aktualizuję opis i klikam przycisk Update.

Jesteśmy znów na ekranie Test Plan Management (Fig. 19). Jesteśmy gotowi do przeprowadzenia testów. Teraz możemy albo wrócić na homepage projektu i kliknąć Execute Tests albo po prostu kliknąć ikonę Test Execution, przypominającą konsolę sterującą (zaznaczona czerwoną ramką na Fig. 19).

Egzekucja, czyli wykonanie testów

Otwiera się ekran Execute Tests (Fig. 20). W kolumnie po lewej wyświetla się zaktualizowana nazwa naszego planu, numer wersji wybranej do testów, a w drzewie na najwyższym poziomie jest nazwa projektu i planu testów (u mnie New web app/Testing new user registration with email). Obok niej, w pierwszej parze nawiasów wyświetla się liczba przypadków testowych, a w drugiej parze nawiasów są liczby oznaczające liczbę testów niewykonanych (not run), testów zaliczonych, czyli tych które przeszły (passed), niezaliczonych (failed) oraz zablokowanych (blocked).

Poziom niżej wyświetla się folder z nazwą scenariusza i informacjami o testach – w tym wypadku wartości są te same, ale w ramach jednego planu testów moglibyśmy mieć więcej scenariuszy i wtedy wartości odzwierciedlałyby stan testów dla każdego scenariusza. Na najniższym poziomie mamy przypadki testowe – jak widać na Fig. 20, TC-4 zostanie wykonany najpierw, gdyż zmieniłem kolejność (patrz Fig. 16 powyżej).

Zaznaczamy pierwszy przypadek do przetestowania i po prawej stronie ukaże się sekcja Test Results on Build [identyfikator builda] (Fig. 21). Pod informacjami o planie testów, buildzie i scenariuszu wyświetli się komunikat o ewentualnym ostatnio wykonanym teście (Last execution) – w naszym wypadku to będzie Not run, gdyż żadnych testów jeszcze nie przeprowadziliśmy.

Dalej mamy szczegóły pierwszego przypadku testowego wyznaczonego do wykonania w pierwszej kolejności.

Oczywiście właściwe testy przeprowadzamy w odpowiednim środowisku, w tym wypadku w przeglądarce, a w TestLinku dokumentujemy wyniki testów. Na potrzeby tego ćwiczenia przeprowadzimy testy symbolicznie.

Przewijamy dalej, do poszczególnych kroków testowych (Fig. 22). Najważniejsze kolumny to Step Actions, czyli działania, np. „wpisanie adresu strony w przeglądarce”, dalej Expected Results, czyli oczekiwany wynik działania, np. „żądana strona internetowa otwiera się”, oraz Execution Status, czyli wynik wykonania kroku. Dodatkowo w kolumnie Execution notes możemy wpisać komentarze i uwagi.

Zaznaczmy sobie wszędzie Passed, czyli kroki zaliczone.

Na dole ekranu (Fig. 23) zapisujemy wynik testu dla całego przypadku  zaliczony 🙂(passed), niezaliczony 😒(failed) lub zablokowany 😮 (blocked). Robimy to przez kliknięcie odpowiedniej emotikonki czy ikonki – buźki lub kółka zębatego (działanie mają takie samo, twórcy TestLinka dają nam po prostu alternatywę).

Na dole strony mamy jeszcze jedno pole na zbiorcze notatki (przydatne głównie w przypadku niezaliczonego lub zablokowanego testu) i możliwość dołączenia pliku – zazwyczaj będzie to zrzut ekranu.

Status testu „zablokowany” oznacza, że nie mogliśmy wykonać danego testu np. ze względu na jakiś bug występujący w systemie i uniemożliwiający rozpoczęcie tego testu.

Jeśli nie chcemy jeszcze zapisywać wyniku testu, możemy zapisać wyniki dla poszczególnych kroków klikając Save Steps Work In Progress Execution.

Po kliknięciu wyniku testu dla pierwszego przypadku automatycznie wracamy do góry ekranu (Fig. 24), gdzie teraz wyświetla się informacja o ostatnio wykonanym teście dla aktualnie zaznaczonego przypadku: data, godzina, kto go przeprowadził i na jakiej wersji, no i oczywiście status, czyli rezultat testu. Informacje te są podane dla aktualnie testowanej wersji (current build) jak i wszystkich wersji zdefiniowanych w naszym projekcie (any build) dla danego przypadku.

Dodam, że jeśli któryś z kroków w ramach przypadku testowego zaznaczymy jako niezaliczony, to cały przypadek możemy nadal oznaczyć jako zaliczony i „wyjdzie na zielono”.

Zwróć też uwagę, że w drzewku po lewej stronie już widać, że jeden test został przeprowadzony, a do przeprowadzenia został jeszcze jeden.

Klikamy więc na kolejny przypadek – u mnie TC-1. Załóżmy, że w kroku siódmym wykryliśmy błąd, bo nie przyszedł mail potwierdzający rejestrację. Odnotowujemy to w komentarzu i zaznaczamy test jako niezaliczony (failed), czyli smutna buźka.😥

Wynik testu dla przypadku TC-1 wyświetla się „na czerwono” i jest widoczny w drzewie po lewej stronie (również nazwa przypadku jest podświetlona na czerwono) (Fig. 25).

Załóżmy, że na backendzie naszej strony została wykonana poprawka. Możemy więc jeszcze raz przeprowadzić test dla tego przypadku. Przechodzimy kolejne kroki i otrzymujemy wynik pozytywny. Klikamy passed i teraz ostatni test wyświetla się „na zielono”. Możemy w górnej sekcji kliknąć przycisk Show complete execution history, żeby wyświetlić wyniki obydwu testów (Fig. 26).

Raportowanie testów

Testy dla obydwu przypadku ukończyliśmy z wynikiem pozytywnym. Możemy teraz kliknąć ikonę Test Reports (w górnej części ekranu – zaznaczona na Fig. 26) lub przejść do strony głównej i tam kliknąć Test Reports and Metrics.

W lewej kolumnie mamy całą listę różnych raportów możliwych do wygenerowania (Fig. 27). Domyślnie jest to format HTML, który potem można wydrukować do PDF. Można wybrać również format Pseudo MS Word, w którym jest dostępnych o wiele mniej opcji raportowania, ale jest wśród nich interesujący nas raport z testów.

Również tutaj można wybrać konkretny plan testów, dla którego chcemy stworzyć raport. Po prawej stronie jest opis różnego rodzaju raportów i parametrów (metrics). Wybierzmy opcję Pseudo MS Word, a następnie Test Report. W części głównej ekranu możemy zaznaczyć, co ma być ujęte w raporcie (Fig. 28).

Domyślnie jest to Test Case Summary, Test results i Step Execution Results. Zaznaczmy jeszcze checkboxy dla Test Case Related Requirements, i Step Execution Notes.

Zaznaczenie folderu na poziomie projektu lub scenariusza wygeneruje raport dla tego poziomu. Gdybyśmy mieli więcej scenariuszy w tym projekcie, możemy mieć raport dla wszystkich lub tylko dla wybranych scenariuszy. W moim przypadku nie będzie żadnej różnicy.

Po zaznaczeniu folderu projektu automatycznie otwiera się okno dialogowe do zapisania pliku Word.

Raport wygenerowany z mojego projektu możesz pobrać tutaj jako plik PDF:

W raporcie uwzględniony jest aktualny wynik testów, czyli w przypadku TC-1, który przeszedł test za drugim razem, w raporcie będzie uwzględniony ten ostatni, pozytywny wynik testu (Fig. 29).

Żeby zapisać raport w formacie PDF, generujemy raport w MS Word i potem z Wordzie zapisujemy jako PDF („Zapisz jako…”) albo generujemy raport w HTML, a potem klikamy przycisk Print obok menu wyboru formatu (Fig. 30).

Tworzenie portfolio testera

Jeśli nie mamy komercyjnego doświadczenia w testowaniu, jednym ze sposobów na zaprezentowanie swoich kompetencji potencjalnemu pracodawcy jest samodzielne testowanie jakiejś aplikacji czy strony internetowej i tworzenie dokumentacji w narzędziu takim jak TestLink. Portfolio złożone ze i przypadków i scenariuszy testowych, planu testów oraz zbierających to wszystko raportów z testów możesz umieścić na własnej stronie internetowej. Dokumentację możesz oczywiście uzupełnić o zrzuty ekranu. Dorota napisała artykuł ze szczegółowym opisem, jak założyć stronę internetową na platformie WordPress i jak umieścić tam swoje portfolio.

Jeśli nie masz czasu czy ochoty na tworzenie strony, raport z testów możesz wrzucić np. na Google Drive i udostępnić link rekruterowi czy przedstawicielowi pracodawcy. Pamiętaj tylko, żeby w ustawieniach udostępniania (niebieski przycisk „Share”) albo wpisać adres mailowy osoby, która ma mieć wgląd do tego dokumentu Google Docs, w polu, które wyróżniłem na zielono na Fig. 31. Albo zmienić ustawienia prywatności – Change to anyone with the link (wyróżnione czerwoną ramką na Fig. 31).

Wtedy wgląd do dokumentu będzie miała dowolna osoba, której udostępnisz ten link (Fig. 32).

Te kwestie są prawdopodobnie oczywiste dla Ciebie, ale czasami nawet najwięksi „wyjadacze” zapominają o takich banalnych detalach! 😊

Zakończenie

Znowu wyszedł bardzo obszerny wpis, choć wydaje mi się, że zaledwie liznąłem temat. Omówiłem jednak najważniejsze funkcje TestLinka i mam nadzieję, że cykl tych trzech artykułów o TestLink pomoże Ci rozpocząć lub odświeżyć swoją znajomość z tym narzędziem, ćwiczyć pisanie dokumentacji i w ten sposób przygotowywać się do pracy testera. Jeśli masz jakieś pytania, uwagi lub życzenia, śmiało pisz w komentarzu pod artykułem. W miarę naszych możliwości postaramy się jak najlepiej pomóc. 😎

P.S. W sklepie Wyszkolewas pojawił się nowy e-book!!! 

Znajdziesz w nim odpowiedzi na 105 pytań dotyczących testowania oraz 7 pytań miękkich ze wskazówkami, jak na nie odpowiedzieć. E-book to repetytorium wiedzy przeznaczone dla osób, którzy szukają pracy jako junior tester, również tych z doświadczeniem, i chcą się dobrze przygotować do rozmów kwalifikacyjnych.