Dokumentacja testowa – jak ją stworzyć w Testlink?

W poprzednim odcinku zainstalowaliśmy pakiet TestLink i utworzyliśmy pierwszy projekt testowy.

W tym artykule omówimy korzystanie z podstawowych funkcji, przede wszystkim z punktu widzenia junior testera chcącego poćwiczyć tworzenie dokumentacji testowej, czyli specyfikacji wymagań, scenariuszy i przypadków testowych.

W przeglądarce wpisujemy http://127.0.0.1/testlink lub localhost/testlink.

Logujemy się do TestLinka. Mam nadzieję, że Ty lub Twoja przeglądarka pamiętacie login i hasło. 😊

Panel administratora Testlink

Ponieważ w poprzednim wpisie utworzyliśmy pierwszy projekt, po zalogowaniu powinna się teraz wyświetlić strona domowa – panel administratora, jak na zrzucie ekranu poniżej (Fig. 1). W prawym górnym rogu wyświetli się lista projektów testowych, w tym wypadku jeden, którym niedawno stworzyliśmy.

Dokumentacja testowa: specyfikacja wymagań

Przechodzimy do Requirement Specification, gdzie wpiszemy przykładowe wymagania dotyczące rejestracji nowych użytkowników.

Po kliknięciu „Create” (Fig. 2)  otwiera się okno (Fig. 3), w którym wpisujemy ID, tytuł oraz zakres (ang. Scope) Specyfikacji Wymagań (ang. Requirement specifications). Tu chodzi o ogólną nazwę i krótki opis zakresu specyfikacji. Możemy też wybrać, czy w specyfikacji będą wymagania systemowe czy wymagania użytkownika.

Po kliknięciu „Save” otworzy się kolejny ekran z możliwością wypełnienia kolejnego formularza specyfikacji, ale zamiast tego zaznaczamy utworzony dokument, w moim wypadku Web App Req 1: New user registration, żeby wyświetliły się szczegóły (Fig. 4).

Po kliknięciu ikony koła zębatego (zaznaczone na czerwono powyżej) otwiera się widok możliwych do wykonania operacji dotyczących Specyfikacji Wymagań: utwórz, edytuj, usuń, zaimportuj, wyeksportuj, utwórz nową wersję, itd.

Po naciśnięciu „Create” w sekcji Requirement Operations, otwiera się formularz (Fig. 5), w którym wpisujemy identyfikator, tytuł wymagania, np. Registration with email, i zakres wymagania. Poniżej mamy możliwość ustawienia statusu i typu wymagania, a także liczby potrzebnych przypadków testowych.

Po zapisaniu tego wymagania, albo później, gdy rozwiniemy folder projektu w drzewku po lewej stronie i zaznaczymy to wymaganie, wyświetlą nam się poniższe informacje (Fig. 6). Dodatkowo możemy dopisać pokrycie tego wymagania testami (ang. Coverage) oraz powiązania z innymi specyfikacjami (related to, parent of, child of, blocks, depends on). Oczywiście dostępne są inne opcje: tworzenie wersji wymagania, dołączanie plików, itd.

Dopiszmy sobie jeszcze dwa wymagania: rejestrowanie nowego użytkownika przez konto Facebook oraz konto Gmail. W tym celu należy zaznaczyć myszką folder specyfikacji – w moim przykładzie Web App Req. 1: New user registration – i kliknąć koło zębate, żeby utworzyć kolejne wymaganie (patrz Fig. 4).

Jak widać w drzewie folderów na ilustracji poniżej (Fig. 7), stworzyłem trzy wymagania w ramach Specyfikacji Wymagań pod nazwą New User Registration. Zaznaczając folder New web app, w kolumnie po prawej mamy możliwość utworzenia kolejnej Specyfikacji Wymagań, np. dotyczącej logowania się użytkowników (przycisk „Create” zaznaczony zieloną elipsą).

Na początku ten workflow może Ci się wydawać zagmatwany i skomplikowany, ale schemat jest podobny przy tworzeniu scenariuszy i przypadków testowych, więc wszystko powinno Ci się rozjaśnić i utrwalić.

Specyfikacja testów: scenariusz i przypadki testowe

Spójrz jeszcze raz na ekran powyżej. Czerwona strzałka wskazuje ikonę Test Specification, za chwilę przejdziemy do tej sekcji. Możemy też wybrać ikonę Homepage i wrócić do ekranu startowego i tam odnaleźć link do Test Specification (te funkcjonalności są wyświetlane alfabetycznie). Zwróć też uwagę na ikonki u góry ekranu: Homepage, Requirement Specification, Test Specification, User Management i inne, którymi teraz nie będziemy się zajmować. Te ikonki są cały czas dostępne, gdziekolwiek byśmy nie byli w Testlinku.

Tymczasem przechodzimy do Test Specification. W kolumnie głównej (Fig. 8) domyślnie wyświetla się nasz aktualny projekt (u mnie New web app). Folder tego projektu jest też widoczny w drzewie folderów po lewej. Tam będą się wyświetlać foldery innych projektów testowych, gdy je stworzymy. Wróćmy jednak do aktualnego projektu.

Scenariusz testowy (Test Suite)

Gdy klikniemy koło zębate, wyświetlą się Test Suite Operations oraz ikony operacji na scenariuszach, z których teraz interesuje nas tylko biały plusik na zielonym polu, czyli utworzenie nowego scenariusza testowego (Fig. 9).

Po kliknięciu plusa ukazuje się ekran Create Test Suite (Fig. 10),gdzie wpisujemy nazwę i opis scenariusza. Jest też pole słowa kluczowe (ang. keywords) – jeśli wcześniej takie słowa stworzyliśmy (opcja na ekranie startowym), możemy je przypisać do scenariusza. Słowa kluczowe są pomocne w klasyfikowaniu i późniejszymi wyszukiwaniu i filtrowaniu przypadków testowych. Zapamiętaj, że jest taka opcja, jednak na razie ją pominiemy.

Oczywiście klikamy „Save” i ukazuje się nam ekran pozwalający na tworzenie kolejnego scenariusza. Jednak my zaznaczamy w drzewku po lewej stronie folder scenariusza New User Registration (Fig. 11). Wtedy w głównej części panelu dostępne będą akcje dotyczące scenariusza (Test Suite Operations) oraz przypadków testowych (Test Case Operations). Najeżdżając kursorem na ikonki zobaczymy objaśnienia: tworzenie nowego przypadku/scenariusza, edytowanie scenariusza, oraz bardzo ciekawa funkcja, która się przyda w  trakcie rozbudowywania naszych projektów, tj. przenoszenie lub kopiowanie scenariusza/przypadku testowego do innego scenariusza czy projektu (o tym napiszę więcej na końcu artykułu).

Przypadki testowe (Test Cases)

Teraz jednak kliknijmy na plusik przy Test Case Operations, żeby dodać do scenariusza (w moim wypadku New user registration) pierwszy przypadek testowy. W końcu! 😊

W górnej części ekranu (Fig. 12) możemy zaznaczyć checkbox, żeby po zapisaniu tego przypadku testowego od razu przejść do pisania kolejnego. Na potrzeby tej instrukcji pozostawmy jednak ten checbox odznaczony.

Pamiętając o wcześniej zapisanych wymaganiach, napiszmy odpowiedni przypadek testowy o tytule „New user registration with email”. Następnie wpisujemy warunki wstępne (ang. Preconditions), które należy spełnić, żeby wykonać dany przypadek.

W dalszej części tego ekranu (Fig. 13) wpisujemy streszczenie przypadku testowego (ang. Summary). Niżej możemy ustawić status przypadku (draft, ready for review, final, itd.) – korzystanie z tej opcji będzie zależeć od procedur obowiązujących w danym projekcie. Ważna jest kolejna lista rozwijana, gdzie ustawiamy ważność (ang. Importance) przypadku testowego. Następnie wpisujemy szacowany czas, jaki zajmie wykonanie przypadku (Estimated exec.education (min)).

Również tutaj mamy możliwość przypisania słów kluczowych, jeśli takowe zostały utworzone dla danego projektu.

Na koniec klikamy oczywiście „Create”. W drzewku folderów po lewej zobaczymy nowo utworzony przypadek testowy TC-1: New user registration with email (TC to jest indentyfikator, który ustaliliśmy tworząć projekt testowy) pod folderem scenariusza New user registration. Na ekranie głównym zobaczymy dane, które wpisaliśmy w opisie tego przypadku, Jeśli klikniemy koło zębate, to w górnej części ukaze się szereg opcji (Fig. 14). W Test Case Operations możemy utworzyć nowy przypadek testowy na tym samym poziomie (New sibling) w strukturze projektu ).

Możemy też skopiować aktywny przypadek do innego scenariusza (jeśli taki zostałby utworzony, na razie mamy jednak tylko jeden scenariusz). Przypadek możemy oczywiście edytować lub skasować, itd.

Kroki w ramach przypadku testowego

W tej chwili napiszemy kroki do wykonania tego przypadku testowego. W tym celu klikamy przycisk Create step. Żeby ten przycisk był widoczny, to przypadek, do którego chcemy napisać kroki, musi być zaznaczony w drzewku folderów (Fig. 14).

Otwiera się formularz (Fig. 15), w którym wpisujemy pierwszy krok (Step actions) oraz oczekiwany rezultat (Expected results). Tak na przyszłość warto zapamiętać, że możemy też zmienić sposób wykonania przypadku z manualnego na zautomatyzowany.

Po kliknięciu przycisku „Save & insert” otworzy się formularz, gdzie wpisujemy kolejny krok i oczekiwane wyniki, czynności powtarzamy aż do ostatniego kroku w ramach danego przypadku testowego (Fig. 16).

Jeśli naciśniemy przycisk Copy lub Copy step, to aktualnie edytowany krok zostanie skopiowany jako następny krok, my natomiast pozostajemy nadal w trybie edycji tego pierwotnie napisanego kroku (Fig. 17).

Możemy teraz kliknąć Save & exit. Zobaczymy wtedy listę kroków, z podwójnym, skopiowanym krokiem nr 6 i 7 (Fig. 18). Możemy ten zdublowany krok skasować klikając czerwoną ikonkę z krzyżykiem. Usuńmy więc zdublowany przypadek nr 7.

Możemy też nacisnąć zieloną ikonę z plusem, żeby wstawić dodatkowy krok w dowolnym miejscu sekwencji kroków.

Dla przykładu kliknijmy plusik przy kroku nr 5. Otwiera się nam formularz z nowym krokiem nr 6, a krok, który wcześniej był szósty, przeskakuje na miesjce siódme (Fig. 19). Wpiszę tutaj nowy krok – sprawdzenie potwierdzenia rejestracji w skrzynce mailowej. Tak, wiem, że kolejność kroków jest niewłaściwa. 😊

Klikamy „Save & exit” i mamy listę siedmiu kroków.

No dobra, ale krok nr 6 powinien być na końcu! Jest na to sposób. Klikamy krzyżujące się zielone strzałki w nagłówku tabeli. Wtedy aktywne staną się pola przy numerach poszczególbych kroków i możemy zmienić numerację – w moim przypadku krok 6 zmieniam na 7, a 7 na 6. Zatwierdzam klikając Reorder steps (Fig. 20).

Możemy kliknąć przycisk Resequence steps i „przeciągać” myszką dany krok (drag and drop), ale w tym wypadku zmieniamy tylko kolejność wykonywania tych kroków, a nie ich numerację. I szczerze mówiąc, ta opcja nie jest według mnie user-friendly.

Skoro teraz kroki w ramach przypadku testowego nr 1 są we właściwej kolejności, możemy zajrzeć do opcji dostępnej w dolnej części ekranu (Fig. 21).

Tutaj możemy zmienić status, ważność (importance), tryb wykonywania (Execution type) i szacowany czas wykonywania przypadku testowego (Estimated exec. (min)).

Przypisywanie wymagań do przypadków testowych

Ciekawą funkcją jest powiązanie przypadku testowego z wymaganiami. Żeby to zrobić, klikamy Requirements (domyślnie jest tam wartość None). Otworzy się nowe okno (Fig. 22), w którym mamy listę rozwijaną ze specyfikacjami (Requirement Specification) – akurat na razie przygotowaliśmy tylko jeden taki dokument, więc tutaj nic nie zmieniamy. Natomiast poniżej mamy listę przypisanych wymagań (Assigned Requirements) – na razie jest pusta, a dalej listę dostępnych wymagań (Available Requirements), na której zaznaczamy wymaganie, które chcemy przypisać do aktualnego przypadku. Klikamy „Assign”.

Teraz wymaganie przypisane do przypadku New user registration with email będzie widoczne w sekcji Assigned Requirements (Fig. 23).Możemy teraz zamknąć to okno (Close).

Przypisana Specyfikacja i Wymaganie są teraz widoczne w sekcji Requirements w oknie danego przypadku testowego (Fig. 24).

Zbliżamy się do końca tego długiego, ale man nadzieję, że treściwego wpisu! 😊

Pisanie kolejnych przypadków i scenariuszy testowych

Jako „zadanie domowe” proponuję Ci dopisanie kolejnych przypadków testowych. W moim przykładowym projekcie, zaznaczam folder scenariusza New user registration, klikam koło zębate (patrz czerwona strzałka na Fig. 25), a następnie ikonę z plusem przy Test case operations i powtarzam czynności opisane powyżej. Jak widzisz na zrzucie ekranu (Fig. 25), ja już w tzw. międzyczasie napisałem dwa kolejne przypadki testowe, do których zostały automatycznie przypisane identyfikatory TC-2 i TC-3.

Warto też napisać przypadki testowe realizujące „warianty negatywne”, czyli np. wpisywanie nieprawidłowych/niedozwolonych wartości w formularzu rejestracji.

Jeśli na powyższym ekranie zaznaczymy np. przypadek nr 1, dotyczący rejestracji przez podanie maila, i klikniemy koło zębate, możemy skopiować ten przypadek testowy klikając przycisk „Move/Copy” przy Test Case Operations (Fig. 26).

Ukaże się ekran (Fig. 27) z informacją, że wybrany przeze mnie przypadek testowy mogę skopiować do dowolnego scenariusza, ale tylko w ramach tego projektu testowego (u mnie jest to projekt New Web App). Wybieramy scenariusz (Choose Test Suite) – jeśli mamy ich już więcej – a następnie wpisujemy nazwę tego nowego, skopiowanego przypadku: domyślnie jest to data i godzina tej akcji oraz pierwotna nazwa przypadku, ale oczywiście możemy nadać własną nazwę. Możemy też zaznaczyć (lub nie) dalsze opcje: przypisane słowa kluczowe (Copy Keyword Assignments), przypisane wymagania (Copy Requirement Assignments), a także zaznaczyć, czy chcemy, żeby skopiowany przypadek był na szczycie czy na spodzie drzewa folderów.

Klikamy Copy i mamy gotowy kolejny przypadek testowy (u mnie TC-4: New user registration with incorrect email), który trzeba teraz tylko zedytować (Fig. 28). A więc zaznaczamy go w drzewku folderów, klikamy koło zębate oraz przycisk „Edit” przy Test Case Version Operations, żeby zedytować opis przypadku. W moim scenariuszu zmienię opis (Summary) na „The objective is to test whether a new user can register to the web app with an invalid email”.

Następnie przechodzę do edycji odpowiedniego kroku, w tym wypadku kroku nr 4 dotyczącego wpisywania adresu email (Fig. 29).

Kroki mogę edytować, dodawać, usuwać, przestawiać ich kolejność, ale dzięki możliwości kopiowania przypadków testowych nie muszę wszystkiego przepisywać.

Możesz też stworzyć nowy scenariusz, zaznaczając – UWAGA! – folder projektu (u mnie jest to New web app), klikając kółko zębate, a następnie klikając plusik przy Test Suite Operations (Fig. 30). Ten kolejny scenariusz może zawierać przypadki testowe dla kolejnej funkcjonalności naszej aplikacji webowej czy oprogramowania, np. możemy testować logowanie się zarejestrowanych użytkowników.

Jak widzisz, w lewej kolumnie widać też panel filtrujący przypadki i scenariusze testowe wyświetlane w strukturze folderów według tytułu przypadku, wg scenariusza, platformy (chodzi np. o system operacyjny czy przeglądarkę, na której przeprowadzamy testy, a które możemy zdefiniować poprzez funkcję Platform Management dostępną z ekranu startowego TestLinka), a także według statusu, ważności i trybu wykonania. Funkcja ta jest przydatna przy większej liczbie rozbudowanych projektów.

Już naprawdę na koniec chciałbym jeszcze zwrócić Twoją uwagę na to, żeby w lewej kolumnie zaznaczony był checkbox Update tree after every operation. Dzięki temu każde dodanie, usunięcie czy skopiowanie przypadku lub scenariusza testowego jest widoczne w drzewku folderów projektu. Ten checkbox jest zaznaczony domyślnie przy tworzeniu specyfikacji testów.

Co w następnym wpisie?

W trzecim, chyba ostatnim odcinku o TestLinku napiszę o tworzeniu planu testów (Test Plan), określaniu wersji (Build), wykonywaniu testów (Execute Tests) oraz generowaniu raportów z testów (Test Report). Pokażę również, jak z pomocą TestLinka możesz stworzyć swoje testerskie portfolio, które możesz umieścić na swojej stronie internetowej.

Jeśli macie jakiekolwiek pytania, uwagi czy sugestie do pierwszych dwóch części Sagi o TestLinku, to piszcie w komentarzach! 😊

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.