Produkty procesu testowego – od podstawy do scenariusza testowego

Co w przypadku, kiedy projekt dopiero się zaczyna i nie istnieje żadna podstawa testów? Jaka jest metoda działania w takiej sytuacji? W tym wpisie przybliżę procesy, jakie zachodzą w celu otrzymania gotowej dokumentacji testowej projektu. Innymi słowy – poznasz najważniejsze produkty testowania, tworzone podczas procesu testowego.

Na początku był… kontekst

Punktem wyjściowym każdego projektu, do którego implementujesz testowanie jest jego kontekst. Do wytwarzanego projektu należy opracować dobry proces testowy, który później zostanie uzupełniony odpowiednimi czynnościami i zadaniami testowymi oraz produktami prac testerskich. Kontekst zależny będzie przede wszystkim od dziedziny biznesowej, którą się zajmujesz oraz wszelkimi ograniczeniami związanymi z powodzeniem projektu, tj.:

• budżet i zasoby,
• harmonogramy,
• złożoność,
• wymagania związane z umowami i przepisami,
• polityka i strategia obowiązująca w Twojej organizacji,
• normy i standardy.

Etapy

Wszelkie produkty prac testowych jakie opiszę poniżej, są ujęte przez sylabus ISTQB w procesie testowym. Dzielą się one na konkretne etapy:

• planowanie testów,
• monitorowanie testów i nadzór nad testami,
• analiza testów,
• projektowanie testów,
• implementacja testów,
• wykonywanie testów,
• ukończenie testów.

Zgodnie z wybranym kontekstem projektu, niektóre z tych procesów mogą następować po sobie, nakładać się na siebie lub jak w przypadku monitorowania testów i nadzoru nad testami, występować przez cały czas jego trwania. Sam proces testowy jest jednak na tyle rozbudowany, że z pewnością zająłby dodatkowy wpis. Pozostańmy więc w obrębie produktów testowych. Zalążkiem dokumentacji testowej staje się więc podstawa testów.

Podstawa testów

Początkiem każdego procesu będzie ustalenie celów testowania. W tym miejscu znajdziemy wymagania i dokumentację dla projektu, który rozwijamy. Opierając się na wyżej wspomnianym kontekście, utworzona zostanie podstawa testów i kryteria osiągnięcia celu testowania. Takie wysokopoziomowe cele zostaną ujęte w harmonogramie, według którego będziesz pilnować wyznaczonych terminów.

Pomocne w wytworzeniu mierzalnych efektów pracy, będzie narzędzie do zarządzania testowaniem takie jak Jira. Mierzalne efekty pracy to np. zebrane wymagania biznesowe aplikacji, wymagania funkcjonalne, schematy przejść, projekty środowisk oraz wszystkie  produkty, które sprawdzą zachowanie funkcjonalne i niefunkcjonalne testowanego systemu.

Historyjki użytkownika

Najczęściej spotykaną przeze mnie formą dobrze opisanych produktów testowych są utworzone historyjki użytkownika, których grupy tworzą tzw. opowieści. Takie historyjki i opowieści objęte są śledzeniem, spełniając przy tym jedną z głównych ról dobrego procesu testowego – nieustannego monitorowania i sprawdzania poziomu ukończenia testów. Spisane wymagania biznesowe są następnie przeobrażane w przypadki testowe, produkt prac testowych, który pozwala na bardziej techniczny zapis, jak ma zostać oprogramowane wybrane wymaganie biznesowe.

Do podstaw testów można również zaliczyć (opierając się na kontekście) wszystkie wspierane przez projektowany system urządzenia, jak np. modele konkretnych samolotów/elementów ich wyposażenia, modele telefonów, laptopów itp.

Unika się w tym miejscu wszelkich ryzyk, poprzez wnikliwe sprawdzenie pod kątem możliwych pominięć i niejasności.  Mogą one w późniejszym czasie mocno wpłynąć na testowalność systemu. Solidną podstawą testów można określić takie produkty, dla których określone zostały mierzalne kryteria pokrycia. Najczęściej spotykanymi wskaźnikami są Kluczowe Wskaźniki Wydajności.

Pierwsze warunki testowe

Warunek testowy jest nadrzędnym artefaktem przypadku testowego. Można nim nazwać każdy element testowy lub zdarzenie opisane w podstawie testów. Warunki testowe szereguje się według priorytetów, a następnie sprawdza się pokrycie elementów podstawy testów. Opierając się na dowolnym przykładzie, który będzie wymagał wnikliwego sprawdzenia, możesz założyć, że w Twojej dokumentacji powinien istnieć przynajmniej jeden przypadek testowy dla jednego elementu podstawy testów. Często jednak będzie wymagana nawet większa ilość przypadków testowych dla jednego warunku testowego.

Rozpisane na przypadki testowe

W wyniku zaprojektowania warunków testowych powstają przypadki testowe. Każdy przypadek testowy to zbiór informacji, których zbieranie możesz pamiętać ze zgłoszenia defektu:

• dane wejściowe/dane testowe,
• warunki wstępne,
• kroki do wykonania testu,
• rezultat oczekiwany,
• warunki końcowe.

Z przypadków testowych tworzy się zbiory przypadków testowych, które podobnie jak warunki testowe odpowiednio się je priorytetyzuje. Dzielimy je na niskopoziomowe oraz wysokopoziomowe.

Przypadek testowy niskiego poziomu (konkretny)

W sytuacji pojawienia się wyżej wspomnianych, konkretnych danych testowych jak np. dane wejściowe, potrzebne do pokrycia warunku testowego i jego wyniki oczekiwane, którymi można zasilić przypadek testowy wysokiego poziomu, taki przypadek nazywany jest przypadkiem niskiego poziomu. Konkretne wartości są w stanie odpowiedzieć na konkretny cel warunku testowego.

Przykłady: a == ’42’; login: testuser; password: userpassword.

Przypadek testowy wysokiego poziomu (logiczny)

Przypadek testowy ma za zadanie sprawdzić wybrany element testowy np. poprzez zweryfikowanie pewnej ścieżki programu względem testowanego wymagania (podstawy testów). Nie każdy z nich zbudowany jest jednak z danych wejściowych i oczekiwanych rezultatów. W początkowej fazie, udokumentowane warunki testowe przekształca się w przypadki testowe wysokiego poziomu. Dane testowe nie są jeszcze zdefiniowane, wobec tego zapamiętaj ten typ przypadku testowego jako abstrakcyjny. Jego główną zaletą jest możliwość wielokrotnego wykorzystania z racji tego, że bardziej przypomina szablon przypadku testowego. Poprzez użycie różnych danych testowych możesz wykorzystać taki przypadek na wiele sposobów.

Przykłady: dowolna liczba z zakresu a: <0,…,100>; login; password.

Wszystkie powyższe produkty wiąże ważna cecha. Spełniają korzyść testowania na etapie projektowania i oceny podstawy testów, jaką jest wczesne znajdowanie defektów, które mogłyby wpłynąć na powodzenie projektu. Spełniają przy tym zasadę wczesnego testowania. Dzieje się tak dlatego, że na tym etapie najczęściej nie istnieje żadna linijka kodu, a więc wszelkie defekty w dokumentacji charakteryzują się relatywnie niskim kosztem naprawy.

Scenariusz testowy

Scenariusz jest niczym innym jak zapisem kilku przypadków testowych wymaganych do wykonania w określonej kolejności. Polega na szeregowaniu istniejących przypadków testowych w taki sposób, że warunki wyjściowe jednego przypadku testowego, będą warunkami wejścia dla kolejnego w celu pokrycia wybranego obiektu testów. Kilka takich scenariuszy zbiera się następnie w zestawy testów i umieszcza na etapie implementacji do dokumentu zwanego harmonogramem wykonywania testów. Na koniec wybrane zestawy testów będą uruchamiane według wspomnianego harmonogramu wykonywania testów.

Czy procedura testowa?

Sylabus ISTQB spotyka się w tym miejscu z faktyczną praktyką testerską, ponieważ scenariusze bardzo często występują w projektach. Potrafią mieć jednak zgoła inne nazewnictwo w dokumentacji testowej. Według sylabusa to, co w codziennej pracy luźno nazywa się scenariuszem testowym określane jest procedurą testową. Nie jest to jednak ostateczna nazwa tego dokumentu, ponieważ rozwija się o dodatkowe określenie: specyfikacja procedury testowej.

Słowo specyfikacja ma za zadanie podkreślić, że procedura testowa (ale i wszystkie inne specyfikacje w sylabusie) to nic innego jak faktycznie istniejący przedmiot testowania, który jest udokumentowany i śledzony w narzędziach. Najłatwiej będzie przełożyć nazwę na „udokumentowany scenariusz testowy”.

Co charakteryzuje scenariusz testowy?

Scenariusz testowy będzie charakteryzował się następującymi informacjami:

• nazwa scenariusza,
• opis,
• warunki wstępne,
• wymagania (do których się odnosi),
• typ testu (pozytywny/negatywny),
• ID kroku,
• opis kroku,
• oczekiwany wynik,
• rzeczywisty wynik.

Całość procesu

Po utworzeniu struktury z powyższych produktów i rozpoczęcia procesu wykonywania testów zgodnie z harmonogramem, oprócz statusów wykonania dla ww. procedur testowych produktami procesu będą również zgłoszenia defektów. Jak widzisz, zgłoszenie defektu, będące tak podstawową czynnością testerską, jest tak naprawdę jednym z ostatnich produktów testowych w procesie. Całość opisywanego procesu prezentuje się następująco:

Wpis ma zadanie pokazać szerszą perspektywę powstawania produktów w procesie testowym. W dalszej jego części chcę Ci pokazać część praktyczną w odniesieniu do projektu tej strony internetowej. Sprawdź, jak rozpisałbym cele z podstawy testów, warunki testowe, przypadki testowe, scenariusze/procedury testowe.

Podstawa testów – przykłady

Zacznijmy od zebrania wymagań od interesariuszy. Po krótkiej rozmowie wynikły następujące wymagania, które rozpisano jako ogólne cele projektu. Możesz jednocześnie zobaczyć jak w praktyce wygląda ogólnikowy zapis historyjek (user stories) wspomnianych podczas omawiania podstawy testów. Zestaw poniższych historyjek nazywa się opowieścią (epic).

Charakteryzują się specyficzną formą zapisu, która wskazuje na konkretną korzyść po jej spełnieniu. Zwróć uwagę na model zdań:

Jako…(użytkownik) -> chcę…(mieć) -> aby…(uzyskać)

1. Jako użytkownik, chcę mieć dostęp do strony głównej serwisu poprzez wpisanie adresu remigiuszbednarczyk.pl, aby uzyskać możliwość użytkowania serwisu.

Kryteria akceptacji

• istnieje domena remigiuszbednarczyk.pl.
• strona główna istnieje.
• na stronie głównej znajduje się górne menu z nawigacją do stron:
  • O mnie (Strona główna).
  • Jak zostać testerem.
  • Artykuły.
  • Kontakt.

2. Jako użytkownik, chcę mieć dostęp do strony Jak zostać testerem, wtedy znajdę niezbędne informacje jak dokonać tego celu w jednym miejscu.

Kryteria akceptacji:

• Strona Jak zostać testerem istnieje.
• Na stronie głównej znajduje się menu z nawigacją do strony Jak zostać testerem.

3. Jako użytkownik, chcę mieć możliwość dodawania komentarzy na stronie Jak zostać testerem. Serwis będzie posiadał opisaną politykę prywatności, aby sprostać krajowym normom w zakresie przetwarzania danych osobowych RODO. Odniesienie do strony Polityka prywatności będzie umieszczone w stopce.

Kryteria akceptacji:

• strona Jak zostać testerem istnieje.
• istnieje formularz komentarzy na końcu artykułu.
• na stronie głównej znajduje się menu z nawigacją do strony Jak zostać testerem.
• na stronie istnieje stopka.
• strona Polityka prywatności istnieje. Informuje użytkownika jak gromadzone i wykorzystywane są dane osobowe w serwisie.

4. Jako użytkownik, chcę mieć dostęp do strony Artykuły, gdzie znajdę pomocne publikacje na temat testowania oprogramowania.

Kryteria akceptacji:

• strona Artykuły istnieje.
• na stronie głównej znajduje się menu z nawigacją do strony Artykuły.

5. Jako użytkownik, chcę mieć możliwość wysłania przygotowanego formularza ze strony Kontakt, aby móc kontaktować się z twórcą serwisu. Formularz posiada wymagane pola.

Kryteria akceptacji:

• strona Kontakt istnieje.
• na stronie głównej znajduje się menu z nawigacją do strony Kontakt.
• na stronie Kontakt istnieje formularz wysłania wiadomości z polami: Twój e-mail [wymagane], Temat [opcjonalne], Treść [wymagane], przycisk Wyślij.

Warunki testowe – przykłady

Jak widać, niektóre z powyższych celi zawierają dodatkowe warunki testowe, które trzeba będzie ująć w oczekiwanych rezultatach (filtrowanie wiadomości, pola wymagane).

Przypadki testowe – przykłady

Tak rozpisane warunki testowe będą potrzebowały dodatkowych przypadków testowych:

• Na stronie głównej utworzono górne menu umożliwiające nawigację po stronach z wymagań.
• Formularz komentarza filtruje wiadomości będące spamem.
• Formularz wiadomości posiada pola wymagane.
• Istnieje strona Polityka prywatności.

Poniższa lista ma charakter poglądowy i wymienia przypadki testowe dla znanych warunków testowych. Zwróć uwagę, że poniższe przypadki testowe zostały zaprojektowane tak, aby pokryć jak najwięcej wymagań z podstawy testów:

Z racji tego, że na tym etapie powyższa lista składa się z niezależnych od siebie przypadków testowych, następuje spora powtarzalność treści, np. w warunkach wstępnych. Dzieje się tak dlatego, że przypadki nie zostały jeszcze ze sobą powiązane i każdy z nich musi przedstawiać całą napotkaną sytuację od nowa. Przypadki mogą być dodatkowo rozbudowane o wspomniane warunki końcowe, wtedy jeszcze łatwiej będzie zaprojektować procedurę testową.

Jest to jednocześnie jedna z wad projektowania przypadków testowych ze względu na dużą powtarzalność i czasochłonność projektowania. Odpowiedzią na ten problem stają się procedury testowe, które z racji ścisłego powiązania i uporządkowania przypadków testowych, mogą zoptymalizować listę opisywanych przypadków testowych i ich treść. Przykładowo, nie będzie potrzeby każdorazowo sprawdzać czy strona Jak zostać testerem istnieje.

PS. Uważny tester zauważy, że górne menu jest rozpisane w wymaganiach tylko na stronę główną. Jest to celowy zabieg dla zaoszczędzenia Twojego czasu, aby nie tworzyć dziesiątek dodatkowych wymagań i przypadków testowych dla każdej strony w serwisie. Jest to jednocześnie bardzo bezpieczne wymaganie, znacząco skracające listy do pokrycia.  Zważając na kontekst projektu i jego specyfikę (strona internetowa) powinniśmy mieć na uwadze, że menu nawigacji oraz stopka powinny znajdować się na każdej stronie serwisu. Jeśli nie ma tego sprecyzowanego w wymaganiach może to być defekt warty zgłoszenia.

Procedura testowa/Scenariusz testowy – przykłady

Zakładając, że procedura zawiera w sobie uporządkowane przypadki testowe, których warunki końcowe jednego przypadku są warunkami wstępnymi dla kolejnego, odnieśmy się do powyższych przypadków testowych. Naszym celem będzie stworzyć procedurę testową, która sprawdzi możliwość wysyłania formularza wiadomości z poziomu strony Kontakt. Mając to na uwadze, będziemy potrzebować przypadków testowych, które pokryją wymagane do pełnego odtworzenia ścieżki. W szczegółowej procedurze testowej, poza samą stroną Kontakt pojawią się więc następujące przypadki:

• widoczność strony głównej.
• możliwość nawigacji poprzez górne menu na stronie głównej.
• widoczność strony Kontakt.
• wysłanie formularza na stronie Kontakt.
• wysłanie formularza bez podania pola e-mail w formularzu na stronie Kontakt.
• wysłanie formularza bez podania pola treść w formularzu na stronie Kontakt.

Struktura takiej procedury będzie wyglądała następująco:

Uwagi odnośnie scenariusza TS1

Sprawdziliśmy podstawową pozytywną ścieżkę przejścia. Jak widzisz sprawdzanie widoczności pól i przycisków wymaganych do wykonania testu jest tak wnikliwe, jak wymagania na których się opierają. Mamy więc dodatkową weryfikację pól, jednak nie pokrywa ona wymagań zweryfikowania pól wymaganych. W tym celu tworzymy następny scenariusz testowy:

Uwagi odnośnie scenariusza TS2

Jak widzisz test pokrywa wszystkie trzy możliwości błędnego wykorzystania formularza na stronie Kontakt. Nie ma tutaj oddzielnego przypadku testowego dla pola Temat, ponieważ nie podlega ono walidacji jako pole niewymagane.

W ten sposób pokryty został zarówno pozytywny, jak i negatywny test. Dodatkowo wykonanie tych procedur jednej po drugiej nie spowoduje żadnych konfliktów w działaniu systemu. Jest to więc dobry kandydat do zestawu testowego, który później zaplanowany będzie w harmonogramie wykonania testów. I na tym kończy się dzisiejszy artykuł. Zaczęliśmy od zarysu produktów testowych w procesie testowym, a kończymy na konkretnej dokumentacji opartej na działaniu tej strony internetowej.

***

Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester