Co to jest przypadek testowy chyba wszyscy wiedzą? Jeśli nie: Przypadek Testowy (ang. Test Case) jest instrukcją, jak przetestować daną funkcjonalność. Jednak, czego niektórzy mogą nie wiedzieć, przypadki testowe można podzielić na konkretne i logiczne.
Różnica pomiędzy konkretnymi a logicznymi przypadkami testowymi
Konkretne przypadki testowe charakteryzują się tym, że szczegółowo opisują proces testowy. Zawierają kroki do wykonania (w punktach) oraz często posiadają specyficzne dane (wejściowe i wyjściowe), których trzeba użyć w danym przypadku. Jednym słowem są niskopoziomowe. Logiczne przypadki testowe (wysokopoziomowe), są bardziej luźne i naprowadzają tylko testera na ścieżkę testowania, zostawiając miejsce na interpretację.
Jak zwykle, gdy stoimy przed wyborem, trzeba się zastanowić nad wadami i zaletami.
Pokrycie testowe i powtarzalność
Zacznijmy od pokrycia testowego, czyli wskaźnika, jak dokładnie przetestowaliśmy część programu objętą testami. Tutaj lepiej sprawdzą się logiczne przypadki testowe, gdyż każde jego wykonanie jest unikalne. To że są wysokopoziomowe, zostawia miejsce na indywidualne podejście testera, który może sam dobrać dane oraz sposób obsługi danej funkcjonalności. Może to zwiększyć pokrycie testowe. Taka sama liczba logicznych przypadków testowych, testujących te same funkcjonalności, ma większe pokrycie niż z użyciem konkretnych Test Case’ów. Dzieje się tak dlatego, że zawsze są one wykonywane w ten sam sposób – nie ma w nich miejsca na inwencję własną.
Poprzednie zdanie opisuję bardzo ważną zaletę konkretnych przypadków testowych: powtarzalność. Jest ona ważna przy weryfikacji testów, np. podczas audytów. Niestety, wadą logicznych przypadków testowych jest ich słaba powtarzalność.
Pielęgnacja i doświadczenie testera
Jednak logiczne przypadki testowe są o wiele łatwiejsze w pielęgnacji. Zwykle nie trzeba w nich prawie nic zmieniać, gdy testowany obszar ulegnie zmianie, gdyż są tak ogólne (wysokopoziomowe), że dobrze pasują do nowych warunków. Konkretne, wiadomo – delikatna zmiana w systemie i trzeba zmieniać w nich jakiś szczegół.
Warto też zwrócić uwagę na doświadczenie testera. Gdy zna on testowany system lub ma znaczne doświadczenie zawodowe, z łatwością poradzi sobie z logicznymi przypadkami testowymi. Z kolei do niedoświadczonego testera lepiej kierować jest konkretne przypadki testowe. Mamy wtedy pewność, że przetestuje on obszar poprawnie.
Wybór między tymi dwoma sposobami zależy też od wymagań produktowych, czyli tego, co wiemy o testowanym programie. Wyjaśnię to na przykładzie. I to takim, żeby każdy zrozumiał.
Przykład – przypadek testowy logiczny i konkretny
Załóżmy, że naszym testowanym systemem jest automat robiący kanapki. Nawet nie znając żadnych szczegółów, możemy już stworzyć przypadek testowy. Oczywiście użyjemy logicznego wariantu. Może on wyglądać nawet tak banalnie jak: „Dostarcz automatowi składniki; uruchom proces robienia kanapki; oceń wyniki„.
Doświadczony tester, nawet nie znając specyfikacji urządzenia będzie w stanie wykonać tę instrukcję. W miarę jak będzie nam przybywało danych (które są weryfikowalne i pochodzą z wymagań), możemy zacząć tworzyć coraz konkretniejsze przypadki testowe. Gdy będziemy wiedzieli, że automat przyjmuje tylko chleb oraz składniki już przygotowane (pokrojone), oraz że produkuje jedną kanapkę na minutę, możemy stworzyć następujący przypadek testowy (już konkretny):
warunki wstępne: dostępne są składniki (3 kromki chleba, 3 plastry sera, 3 plastry pomidora)
- Uruchom automat czerwonym przyciskiem
- Włóż chleb do przegrody na chleb
- Włóż pozostałe składniki do przegrody na dodatki
- Uruchom proces robienia kanapek zielonym przyciskiem
oczekiwany rezultat: po trzech minutach na tacy z produktami powinny leżeć 3 kanapki
Jak widzicie, oba rodzaje przypadków testowych są wartościowe i mają swoje miejsce w procesie testowym. Od osoby projektującej testy oprogramowania zależy, który w danej chwili wybierzemy.