Jak napisać dobry przypadek testowy?

Często, gdy czas na testy zostaje wydłużony i wyczerpaliśmy przygotowane wcześniej test case’y, musimy bazując m.in. na własnym doświadczeniu stworzyć kolejne testy, które pokryją określone założenia, wytyczne lub obszary. Do tego możemy użyć wielu inspiracji, które musimy zdobyć, aby jakość naszych testów była na jak najwyższym poziomie.

Teoria zawsze w cenie

Wartościowym źródłem informacji od wielu lat jest ISTQB (International Software Testing Qualification Board), a także różne standardy z obszaru testowania oprogramowania. Dobrą praktyką jest kierowanie się standardami odnoszącymi się do testowania oprogramowania. Jednym z nich jest IEEE-610 (IEEE Standard Glossary of Software Engineering Terminology). Określa on podstawową definicję przypadku testowego, a brzmi ona następująco:

Przypadek testowy to zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania opracowany w określonym celu lub dla warunku testowego, jak wykonanie pewnej ścieżki programu lub zweryfikowanie zgodności z konkretnym wymaganiem.

Wielu testerów, mimo przyswojenia tej definicji, wciąż ma problem z określeniem, jak powinien wyglądać dobrze napisany przypadek testowy. Może to być wina złej edukacji testerskiej albo brak odwołania się do ogólnodostępnej wiedzy. A może sama definicja jest niewystarczająca i testerzy potrzebują więcej, aby dobrze zrozumieć ideę przypadku testowego?

Innym ważnym standardem jest IEEE 829-2008, specyfikujący dokumenty używane w procesie testowym.

Rozpoczynając od teorii, postarajmy się stworzyć przykład wzorcowego przypadku testowego.

Własna definicja

Każdy w organizacji ma prawdopodobnie własną strukturę przypadku testowego. To dobrze i, co więcej, powinniśmy dążyć do tego, by konstruowanie testów bazowało na potrzebie jaką mają one realizować oraz naszej wiedzy w tym zakresie. Należy jednak pamiętać, że tworzony przez nas przypadek testowy powinien zawierać pewne stałe, kluczowe elementy składowe takie jak: unikalny identyfikator, warunki wstępne, kroki do wykonania testu, oczekiwany rezultat.

Gdy myślimy o kontrolowaniu jakości, musimy pamiętać, że nasz test powinien zawierać elementy, które dostarczają szeregu informacji potrzebnych podczas realizacji testu, czyli wpływają na jego jakość.

Pamiętajmy, że każdy przypadek może zawierać wiele informacji. Jednak tworząc go powinniśmy dostosowywać ilość danych do kontekstu danego przypadku, a każdy z nich będzie zawierał różną ich ilość w zależności od swej złożoności.

Przypadki ze szczegółami czy bez?

Przypadki testowe możemy podzielić na przypadki testowe niskiego oraz wysokiego poziomu.

Przypadek testowy niskiego poziomu (ID 1.1) to przypadek testowy z konkretnymi (na poziomie implementacji) wartościami wejściowymi i wynikami oczekiwanymi. Logiczne operatory z przypadków testowych wysokiego poziomu są zamieniane na konkretne wartości, które odpowiadają celom logicznych operatorów.

Przypadek testowy wysokiego poziomu (ID 1.2) to przypadek testowy bez konkretnych (na poziomie implementacji) wartości danych wejściowych i oczekiwanych rezultatów. Używane są w nim operatory logiczne, a rzeczywiste wartości nie są jeszcze zdefiniowane i/ lub dostępne.

Tworzenie przypadków testowych w przeważającej części powiązane jest z wymaganiem. Mogą one być zapisane w formie tzw. user story:

“Jako konkretny użytkownik chcę wypełnić formularz na stronie logowania, wtedy będę miał dostęp do funkcjonalności.“

wraz z kryteriami akceptacji:

“Na stronie głównej znajduje się ekran służący do logowania z polami:

ADRES E-MAIL [wymagane] i HASŁO [wymagane]”

ID 1.1

Tytuł: Poprawne logowanie do aplikacji

Środowisko: http://demo.testarena.pl/zaloguj

Wersja: Demo: 3.1.1085

Warunek wstępny: Niezalogowany użytkownik, posiadający aktywne konto w aplikacji.

Kroki reprodukcji:

1. Wprowadzenie adresu e-mail.
2. Wprowadzenie hasła.
3. Kliknięcie przycisku “Zaloguj”.

Oczekiwany rezultat: Zalogowanie się do aplikacji jako użytkownik.

Warunki końcowe: Zalogowany użytkownik. Widoczny ekran kokpitu.

Dane testowe: Prawidłowy e-mail, prawidłowe hasło (Konkretne dane)

Autor: Krzysztof Kołodziejczyk, k.kolodziejczyk@testy.pl

Jak widzimy, powyższy przypadek testowy został opisany dość szczegółowo, dlatego nie powinno być kłopotu z jego realizacją. Opisany wyżej przypadek prowadzi nas również do pozytywnego rezultatu. Szczegółowość może być zaletą, ale niestety wadą takiego rozwiązania jest czas, który musimy przeznaczyć na jego napisanie i utrzymanie.

Nie należy zapominać o przypadkach negatywnych, które mogą być weryfikacją walidacji pól tekstowych, np. przy wprowadzeniu błędnego formatu adresu e-mail.

ID 1.2

Tytuł: Logowanie do aplikacji

Środowisko: Wspierana przeglądarka

Kroki do wykonania:

1. Przejście na stronę logowania do aplikacji.
2. Wypełnienie formularza.
3. Kliknięcie przycisku “Zaloguj”.

Oczekiwany rezultat: Poprawne logowanie do konta

Powyższy przypadek testowy jest bardziej ogólnikowy i wymaga mniej czasu na jego napisanie. Przypadek ten wymaga jednak większego doświadczenia i wiedzy od osoby realizującej go, co jest pewnym minusem takiego rozwiązania.

Cele przypadku

Pamiętajmy również, by tworzone przypadki testowe spełniały swoje najważniejsze cele, takie jak: 

• Wyznaczanie pośrednio i bezpośrednio miary oraz metryki jakości testowanego oprogramowania;
• Powinny być wykonywalne;
• Powinny być nastawione na znalezienie defektów;
• Powinny oceniać zgodność z dokumentacją;
• Powinny weryfikować poprawność systemu;
• Powinny minimalizować koszty wsparcia technicznego;
• Powinny dostarczać informacje wspomagające decyzję o wstrzymaniu lub wprowadzeniu systemu na środowisko produkcyjne.

Techniki projektowania testów

Celem przyjętych technik projektowania testów według sylabusa ISTQB jest zdefiniowanie warunków testowych, przypadków testowych i danych testowych. Klasyczny podział wyróżnia trzy techniki: czanoskrzynkowe i białoskrzynkowe oraz oparte na doświadczeniu.

Techniki czarnoskrzynkowe (inaczej nazywane również behawioralnymi) można nazwać takie, które bazują na analizie podstawy testów. Jak czytamy dalej w sylabusie, techniki te bazują na obiekcie testowym, z definicji nie odnosząc się do struktury wewnętrznej modułu bądź systemu. Techniki  mogą być wykorzystywane zarówno w testach funkcjonalnych, jak i niefunkcjonalnych.

Przechodząc do drugiej strony podziału, techniki białoskrzynkowe (inaczej nazywane strukturalnymi) bazują na analizie architektury, szczegółowym opisie, wewnętrznej strukturze lub kodzie obiektu testowego. W przeciwieństwie do czarnoskrzynkowych technik testowych, techniki białoskrzynkowe koncentrują się na strukturze, a także na procesach testowanego obiektu.

Trzecim rodzajem technik są te oparte na doświadczeniu. Wykorzystują one zbiór doświadczeń programistów, testerów oraz użytkowników do projektowania, wdrażania i wykonywania testów. Techniki te często łączone są z czarno- i białoskrzynkowymi technikami testowymi. Dają możliwość oceny, jakie elementy powinny zostać przetestowane. Podparcie się doświadczeniem ma również sens w kontekście przyporządkowania technik do danych kategorii. Niejednokrotnie może stać się to problematyczne, gdyż niektóre z technik zawierają elementy wielu kategorii.

Zgodnie z sylabusem ISTQB przykładowe cechy technik można określić prostą charakterystyką, w której zawarte są m.in.:

Techniki oparte na specyfikacji:

• Warunki testowe, przypadki testowe i dane testowe pochodzą z podstawy testu, która może obejmować wymagania oprogramowania, specyfikacje, przypadki użycia i historie użytkowników.
• Przypadki testowe mogą być wykorzystane do odnalezienia luk pomiędzy wymaganiami a ich implementacją w oprogramowaniu, jak również odstępstw od nich.
• Pokrycie może być mierzone na bazie przetestowanych elementów w podstawie testowej i zaimplementowanych do niej technik, jednak technika ta jest nieprecyzyjna.

Techniki oparte na strukturze:

• Warunki testowe, przypadki testowe oraz dane testowe tworzone są na bazie podstawy testowej, która może zawierać np. kod źródłowy, architekturę systemową, szczegółowy projekt lub inne źródło informacji odnoszące się do struktury oprogramowania.
• Pomiar pokrycia mierzony jest na bazie przetestowanych elementów w obrębie danej struktury (przykład: kod źródłowy lub interfejs).
• Specyfikacja wykorzystywana jest zwykle w takim przypadku jako dodatkowe źródło informacji pomagające określić oczekiwany wynik przypadku testowego.

Techniki oparte na doświadczeniu:

• Warunki testowe, przypadki testowe oraz dane testowe pochodzą z podstawy testu, która może obejmować wiedzę i doświadczenia zarówno testerów, programistów, użytkowników jak i innych zainteresowanych stron.

Jest to prosta charakterystyka zebrana w jedną całość, dokładniejszy opis znajdziecie w rozdziale czwartym nowego sylabusa ISTQB oraz w międzynarodowym standardzie (ISO/IEC/IEEE 29119-4) zawierającym opis technik testowych z ich właściwymi miarami pokrycia.

Nieoceniona praktyka

Jak wiemy, praktyka czyni z nas mistrzów. Zachęcamy Was do pisania własnych przypadków testowych.

Źródła

Szerzej o przypadkach testowych można przeczytać w artykule dla “Core Magazine”, którego autorem jest Radosław Smilgin (http://docplayer.pl/243737-Przypadek-testowy-teoria-i-praktyka.html).

Zachęcamy Was również do zapoznania się z książką, której autorem jest Radosław Smilgin: “Zawód tester. Od decyzji do zdobycia doświadczenia.” (https://ksiegarnia.pwn.pl/Zawod-tester.-Od-decyzji-do-zdobycia-doswiadczenia,743423772,p.html).

Szeroko cytowany w tym artykule był oficjalny sylabus ISTQB Poziomu Podstawowego (https://www.istqb.org/downloads/send/51-ctfl2018/208-ctfl-2018-syllabus.html)

Autor: Krzysztof Kołodziejczyk