Przypadki testowe. Planowanie przebiegu testów.

Każdy, kto choć trochę interesował się tematem testowania oprogramowania, słyszał o takich pojęciach jak przypadek testowy, warunek testowy czy scenariusz testowy. Co właściwie kryje się pod tymi pojęciami? W tym artykule postaram się jak najprecyzyjniej opisać wymienione zagadnienia.

 

Przypadek Testowy

Jest to zbiór danych wejściowych, wstępnych warunków, kroków wykonania i oczekiwanych rezultatów. Przypadki testowe opracowywane są w określonym celu lub dla warunków testowych.

 

• Dane wejściowe (wejście) – zbiór danych wejściowych potrzebnych do wykonania danego przypadku testowego. Rzeczywiste dane wejściowe nie zawsze muszą być zdefiniowane.
• Wstępne warunki wykonania – warunki, które muszą zostać spełnione, aby test został wykonany poprawnie.
• Kroki wykonania testu – zdefiniowane i uporządkowane czynności, które należy przeprowadzić w celu wykonania danego przypadku testowego.
• Oczekiwany rezultat – Rezultat, którego spodziewamy się po poprawnym wykonaniu przypadku testowego. Jeśli wartość, którą otrzymaliśmy po zakończeniu testu, zgadza się z oczekiwanym rezultatem, to możemy uznać, że przypadek testowy zakończył się powodzeniem. Oczekiwany rezultat obowiązkowo musi być zdefiniowany przed wykonaniem testu. Jeśli oczekiwane wyniki nie będą jasno określone, wówczas błędny wynik testu może być zinterpretowany jako poprawny.

Ze względu na rodzaj danych wejściowych możemy wydzielić dwa rodzaje przypadków testowych: przypadki wysokiego poziomu i niskiego poziomu.

Przypadek testowy niskiego poziomu (konkretny) – przypadek testowy z zadanymi konkretnymi wartościami wejściowymi i oczekiwanymi wynikami.

Przykład:

Mamy aplikację, która wykonuje działanie dodawania.

Lp.	Pr.*	Nazwa	Wejście	Warunki wstępne	Kroki wykonania	Oczekiwany rezultat
1	1	Dodawanie 2 dodatnich liczb	1, 2	–	1. Wpisanie w pierwsze pole liczby 1. 2. Wpisanie w drugie pole liczby 2. 3. Kliknięcie przycisku „oblicz”.	Na ekranie pojawił się wynik: „3”.

* - Priorytet, skrót będzie stosowany w dalszej części tekstu

Przypadek testowy wysokiego poziomu (logiczny) – przypadek testowy bez konkretnych wartości wejściowych i oczekiwanych rezultatów. Używane są operatory logiczne, ale rzeczywiste wartości nie są jeszcze zdefiniowane. Inna nazwa takiego przypadku to abstrakcyjny przypadek testowy.

Przykład:

Mamy aplikację, która wykonuje działanie dodawania.

Lp.	Pr.	Nazwa	Warunki wstępne	Kroki wykonania	Oczekiwany rezultat
1	1	Dodawanie 2 dodatnich liczb	–	1. Wpisanie w pierwsze pole liczby A. 2. Wpisanie w drugie pole liczby B. 3. Kliknięcie przycisku „oblicz”.	Na ekranie pojawiła się suma liczb A i B.

Warunki wysokiego poziomu dają większą dowolność i ich wykonanie w dużej mierze zależy od testera. Dwie różne osoby mogą wykonać ten sam przypadek, wprowadzając inne dane, zatem konkretne wyniki również się będą różnić. Może nawet dojść do sytuacji, w której u jednej osoby wystąpi błąd, a u drugiej nie.

Przypadki niskiego poziomu stosuje się w testach automatycznych, gdzie czynności są powtarzalne w 100%. Do testów manualnych warto zastosować przypadki wysokiego poziomu i wykorzystać potencjał testera.

Warunek Testowy

Warunek testowy to element lub zdarzenie modułu lub systemu, który powinien być zweryfikowany przez jeden lub więcej przypadków testowych (np. funkcja, transakcja).

Przykład:

Mamy do przetestowania funkcję logowania do jakiegoś systemu.

Warunek Testowy

Lp.	Nazwa	Opis	Oczekiwany rezultat
1	Logowanie	Sprawdzenie funkcji logowania do systemu	Można zalogować się do systemu. System jest bezpieczny i nie wpuszcza nieuprawnionych użytkowników

Przypadki Testowe

Lp.	Pr.	Nazwa	Warunki wstępne	Kroki wykonania	Oczekiwany rezultat
1	1	Próba zalogowania przy wpisaniu poprawnego loginu i hasła	Istnieje użytkownik zarejestrwowany w systemie, na którym można przeprowadzić test.	1. Wprowadzenie poprawnego loginu oraz hasła. 2. Kliknięcie przycisku „zaloguj”.	Użytkownik został zalogowany do systemu.
2	2	Próba zalogowania przy wpisaniu poprawnego loginu i niepoprawnego hasła	Istnieje użytkownik zarejestrwowany w systemie, na którym można przeprowadzić test.	1. Wprowadzenie poprawnego loginu oraz niepoprawnego hasła. 2. Kliknięcie przycisku „zaloguj”.	Użytkownik nie został zalogowany. Pojawia się komunikat „Wprowadzono niepoprawny login lub hasło”.
3	2	Próba zalogowania przy wpisaniu niepoprawnego loginu i hasła	–	1. Wprowadzenie niepoprawnego loginu oraz niepoprawnego hasła. 2. Kliknięcie przycisku „zaloguj”.	Użytkownik nie został zalogowany. Pojawia się komunikat „Wprowadzono niepoprawny login lub hasło”.

Scenariusz testowy

Scenariusz testowy jest to dokument zawierający zbiór przypadków testo wych (kroków) potrzebnych do sprawdzenia poprawności działania systemu w określonym zakresie. Każdy scenariusz powinien być odzwierciedleniem dokładnie określonej funkcjonalności. Znany także jako skrypt testowy lub specyfikacja procedury testowej.

Każdy scenariusz testowy powinien składać się z: identyfikacji scenariusza testowego, wykazu czynności przygotowawczych, przypadków testowych, czynności końcowych.

• Identyfikacja scenariusza testowego – w tej sekcji dokumentowane są takie dane jak: identyfikator i nazwa scenariusza, opis scenariusza (cele), typ scenariusza (np. testy funkcjonalne, bezpieczeństwa).
• Wykaz czynności przygotowawczych scenariusza testowego – spis wszystkich czynności, które należy wykonać przed przystąpieniem do wykonywania danego scenariusza testowego. Takimi czynnościami przygotowawczymi mogą być: weryfikacja poprawności instalacji i konfiguracji testowanego oprogramowania, weryfikacja narzędzi potrzebnych do wykonania i udokumentowania testów, weryfikacja użytkowników i ich uprawnień niezbędnych do przeprowadzenia testów.
• Wykaz przypadków testowych – w tej sekcji należy zidentyfikować i uporządkować wszystkie przypadki testowe przewidziane do realizacji danego scenariusza testowego.
• Wykaz czynności końcowych scenariusza testowego – wykaz czynności, jakie należy wykonać po zakończeniu testów w ramach danego scenariusza. Są to czynności, bez których niemożliwe byłoby wykonanie kolejnych scenariuszy. Mogą być to również czynności wynikające z polityk bezpieczeństwa.

Przykład:

Mamy do przetestowania nową funkcjonalność systemu.

Scenariusz Testowy

Id	Nazwa	Opis	Typ	Czynności przygotowawcze	Czynności końcowe
1	Dodawanie komentarzy pod postem	Sprawdzenie poprawności działania funkcjonalności dodawania komentarzy pod postami.	Testy funkcjonalne	1. Sprawdzić czy posiadamy odpowiednią wersję aplikacji. 2. Dodać post pod którym będzie można dodawac komentarze.	Usunąć post wraz ze wszystkimi komentarzami.

Przypadki Testowe

Lp.	Pr.	Nazwa	Warunki wstępne	Kroki wykonania	Oczekiwany rezultat
1	1	Dodanie komentarza poprzez przycisk „Skomentuj”	Istnieje post, pod którym można dodać komentarz.	1. Wpisać treść w pole z komentarzem. 2. Wpisać treść w pole z podpisem. 3. Kliknąć przycisk „Skomentuj”.	Komentarz został dodany. Na liście komentarzy prezentuje się nowo dodany komentarz. Licznik komentarzy wzrósł o jeden.
2	1	Dodanie komentarza poprzez wciśnięcie klawisza enter	Istnieje post, pod którym można dodać komentarz.	1. Wpisać treść w pole z komentarzem. 2. Wpisać treść w pole z podpisem. 3. Zaznaczyć checkbox „Wciśnij Enter, aby dodać komentarz”. 4. Wcisnąć klawisz enter.	Komentarz został dodany. Na liście komentarzy prezentuje się nowo dodany komentarz. Licznik komentarzy wzrósł o jeden.
3	2	Próba dodania komentarza bez treści	Istnieje post, pod którym można dodać komentarz.	1. Wpisać treść w pole z podpisem. 2. Kliknąć przycisk „Skomentuj”.	Na ekranie pojawia się komunikat o obligatoryjności pola komentarz. Komentarz nie został dodany.
4	2	Próba dodania komentarza bez podpisu	Istnieje post, pod którym można dodać komentarz.	1. Wpisać treść w pole z komentarzem. 2. Kliknąć przycisk „Skomentuj”.	Na ekranie pojawia się komunikat o obligatoryjności pola podpis. Komentarz nie został dodany.

Powyżej przedstawiłam kilka przykładowych przypadków testowych, ale oczywiście można również sprawdzać, co się stanie, gdy wpiszemy zbyt dużo znaków, a co, gdy wpiszemy niedozwolone znaki.

 

Na co zwrócić uwagę, pisząć przypadki testowe ?

Tworząc przypadki testowe, warto pamiętać, aby spełniały swoje najważniejsze cele w procesie testowym. Powinny być miarą jakości oprogramowania oraz powinny pomagać stronie biznesowej w podejmowaniu decyzji odnośnie dalszego rozwoju produktu. Przypadki testowe powinny również wykrywać defekty i niezgodności w testowanym systemie. Jeżeli nawet nie zostanie znaleziony błąd, to nie oznacza to, że przypadki zostały skonstruowane błędnie. Dostajemy wówczas informację na temat jakości aplikacji oraz zgodności ze specyfikacją. Tester lub analityk jakości powinien zapewnić skuteczność przypadków w znajdywaniu defektów.

Klasa równości

Klasa równoważności jest to zbiór danych o podobnym charakterze i sposobie przetwarzania, używanych do przeprowadzenia testu. Wystarczy sprawdzenie działania danej metody dla kilku elementów z klasy równoważności, aby uznać ją za poprawną. Dzięki temu jesteśmy zwolnieni z testowania wszystkich elementów w zbiorze.

Klasy równoważności dzielą się na klasy poprawności oraz klasy niepoprawności.

• Klasy poprawności – zbiory wartości, dla których przewidujemy poprawne działanie programu.
• Klasy niepoprawności – zbiory wartości, dla których przewidujemy błędne działanie programu.

Przykład:

Mamy system, w którym mogą rejestrować się tylko osoby w przedziale wiekowym od 18 do 110 lat. Chcemy sprawdzić poprawność walidatora tych danych. Klasy, jakie powinniśmy rozpatrzyć, to wartości mniejsze od minimalnej dopuszczalnej wartości (klasa niepoprawności): {-5,0,17}, wartości zawierające się w dopuszczalnym przedziale (klasa poprawności): {20, 44, 78}, oraz wartości większe od maksymalnej dopuszczalnej wartości (klasa niepoprawności): {120, 200, 10000}.

Wartości brzegowe

Wartość brzegowa to wartość znajdująca się na krawędzi danej klasy równoważności. Istnieją poprawne wartości brzegowe – wartości wewnątrz klasy równoważności; oraz niepoprawne wartości brzegowe – wartości poza klasą. Projektując przypadki testowe, należy pamiętać o pokryciu zarówno poprawnych, jak i niepoprawnych wartości brzegowych. Technika wartości brzegowych jest łatwa w stosowaniu i znajduje dużo defektów. Technika ta często jest uznawana za rozszerzenie techniki klas równoważności.

Przykład:

Weźmy nasz system, w którym mogą się rejestrować tylko osoby w wieku od 18 do 110 lat. Testowane wartości brzegowe: {17,18, 110, 111}.

 

Czy więcej znaczy lepiej?

Testując oprogramowanie, nie da się sprawdzić wszystkich scenariuszy, co sprawia, że nie jest możliwe znalezienie wszystkich błędów. Bardzo ważne jest podjęcie decyzji, co testujemy, a czego nie. Co testujemy w pierwszej kolejności, a co później. Często bywa, że gdy błąd zostanie poprawiony, to ujawniają się kolejne defekty. Należy zdecydować się, na których obszarach najbardziej się skupić. Nie wszystkie przypadki testowe są tak samo ważne z punktu widzenia jakości systemu, czasu oraz wymagań klienta. Zatem więcej przypadków to nie znaczy, że aplikacja będzie lepiej przetestowana, ponieważ należy zwracać uwagę na priorytety.

Priorytety Przypadków

Nadając priorytety przypadkom testowym, należy zastanowić się, który obszar aplikacji jest najbardziej podatny na błędy. Przy skomplikowanych funkcjonalnościach istnieje duże prawdopodobieństwo, że poprawka błędu odsłoni kolejne defekty. Poniżej obszary, w których najczęściej występuje duża ilość defektów:

• złożone funkcjonalności – jest to jeden z najczęstszych czynników sprawiający powstawanie błędów. Programiści nie są w stanie przewidzieć wszystkiego, pisząc kod, dlatego przy skomplikowanych funkcjonalnościach często zdarza im się coś przeoczyć.
• obszary, które zostały zmodyfikowane lub przepisane – w takich miejscach powinny wystarczyć testy regresywne, jednak przypadkom regresywnym również warto nadać priorytety.
• funkcjonalności tworzone przez większą liczbę osób – im więcej osób zaangażowanych w jeden projekt, tym większe problemy z komunikacją. Informacje często bywają zniekształcone, źle zinterpretowane lub pominięte. Takie zjawiska mogą zachodzić zarówno przy tworzeniu kodu, jak i przy testach.
• funkcjonalności tworzone pod presją czasu – błędne estymacje czasu, nieprzewidziane sytuacje, problemy w komunikacji wpływają na opóźnienia w fazie kodowania i w fazie testów. Pracując pod presją czasu, łatwo jest coś przeoczyć i popełnić błąd. Brak czasu zmusza do pomijania zaplanowanych ścieżek i do stosowania skrótów. W testach można w ten sposób przeoczyć bardzo dużo defektów.

Zatem przy nadawaniu priorytetów przypadkom testowym należy wziąć pod uwagę następujące czynniki: złożoność funkcjonalności, ważność funkcjonalności z punktu widzenia biznesowego, widoczność funkcjonalności dla klienta końcowego, wpływ funkcjonalności na finanse, zmodyfikowane funkcjonalności, funkcjonalności tworzone pod presją czasu, podobne funkcjonalności, w których występowały problemy.

Przykład:

Mamy do przetestowania wysyłanie wiadomości za pomocą komunikatora internetowego.

PRZYPADKI TESTOWE

Lp.	Pr.	Nazwa	Warunki wstępne	Kroki wykonania	Oczekiwany rezultat
1	1	Wysłanie wiadomości tekstowej.	Istnieje 2 użytkowników systemu, pomiędzy którymi można przeprowadzić rozmowę.	1. Wpisać w pole z wiadomością ciąg znaków. 2. Kliknąć przycisk „wyślij”	Adresat otrzymuje wiadomość z treścią, którą wpisał nadawca.
2	2	Wysłanie emotikony.	Istnieje 2 użytkowników systemu, pomiędzy którymi można przeprowadzić rozmowę.	1. Wpisać w pole z wiadomością ciąg znaków przedstawiający emotikonę (np. „:)”). 2. Kliknąć przycisk „wyślij”	Adresat otrzymuje wiadomość z emotikoną. Emotikona prezentuje się w postaci animowanego gifa.

Powyżej przykład dwóch przypadków testowych sprawdzających funkcjonalność wysyłania wiadomości w komunikatorze internetowym. Pierwszy przypadek ma wyższy priorytet, gdyż wysyłanie wiadomości tekstowych jest podstawową potrzebą użytkownika końcowego, który korzysta z komunikatora. Wstawianie emotikon jest dodatkowym „bajerem”, więc można to sprawdzić w drugiej kolejności.

 

Narzędzia

Zanim przystąpimy do tworzenia przypadków testowych, należy się zastanowić, z jakich narzędzi skorzystamy. Na rynku jest wiele aplikacji ułatwiających zarządzanie procesem testowym, np. TestLink, TargetProcess. Moim zdaniem równie wygodną formą jest arkusz kalkulacyjny. Przypadki i scenariusze zawarte w tabelach wyglądają przejrzyście i mamy do nich szybki dostęp.

 

Podsumowanie

Projektowanie przypadków testowych jest usystematyzowaniem pracy testera, jednak nie jest konieczną czynnością. W dużej mierze zależy to od firmy, dla której pracuje tester. Bywa, że w danej firmie wymagana jest obszerna dokumentacja z testów, ale są i firmy, w których to jest zbędne. Uważam jednak, że przypadki testowe powinny przede wszystkim pomagać testerowi w procesie sprawdzania poprawności oprogramowania, ponieważ porządkują pracę i wiadomo, ile jeszcze zostało nam do przetestowania. Sprawdzając jakiś moduł, łatwo jest wpaść w „wir testowania” i skupić się na jednym małym szczególe, podczas gdy najważniejsze funkcjonalności nie zostały jeszcze sprawdzone. Przypadki testowe przypominają nam o priorytetach, które są bardzo ważne w procesie testowania i przydatne w momencie, gdy kurczy się czas na testy. Należy również pamiętać, że projektując przypadki testowe, nie jesteśmy w stanie pokryć danej funkcjonalności w 100%, gdyż nawet najlepszy tester nie jest w stanie przewidzieć wszystkiego. Tak samo nie jest możliwe znalezienie wszystkich błędów w systemie, ale należy dążyć do tego, aby wszystkie krytyczne błędy zostały wykryte.

 

Karolina Kowalska