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.
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.
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 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 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.
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.
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ó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.
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ść 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}.
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.
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:
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.
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.
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