Czy przypadki testowe to zawsze dobre rozwiązanie?
Może testowanie nie powinno opierać się na niskopoziomowych, szczegółowych krokach do wykonania?
Konserwatyści mogą poczuć się urażeni pytaniem zadanym w tytule, ale w świecie testerskim zauważalne jest zjawisko odchodzenia od klasycznych przypadków testowych. Rozumiem ten trend i (co więcej) sam go stosuję - a w niniejszym tekście wyjaśnię Wam dlaczego.
Czas to pieniądz
Nie jestem przeciwnikiem przypadków testowych - ba, wręcz widzę w nich wiele korzyści. Ale te korzyści są widoczne wyłącznie, gdy przypadki testowe mogą liczyć na odpowiednie zadbanie ze strony zespołu. Przypadki testowe muszą być stale aktualizowane - tylko wtedy mają wartość i zapewniają więcej plusów niż minusów. Przestarzałe testy skutkują pojawieniem się paradoksu pestycydów - a to może doprowadzić do niebezpiecznego przekonania o braku błędów w oprogramowaniu. Oczywiście, klasyczne przypadki testowe mają swoje uzasadnienie - choćby przy testowaniu rozbudowanych systemów, gdzie za proces utrzymania jakości odpowiedzialnych jest wielu testerów. W takiej sytuacji dostępne są zasoby (a konkretnie ludzie i czas), by te przypadki utrzymywać i skutecznie wykonywać.
Rzeczywistość nie jest jednak taka piękna i często zdarza się, że testowaniem zajmuje się jedna, może dwie osoby. Jak wtedy znaleźć czas na zarządzanie scenariuszami testowymi? Czasem jest to po prostu niemożliwe i trzeba sięgnąć po inne rozwiązania.
To co zamiast przypadków testowych?
Ograniczone zasoby (czy prościej mówiąc brak rąk do pracy) nie są argumentem za porzuceniem jakiegokolwiek dokumentowania testów i ich chaotycznego wykonywania. Proces utrzymania jakości musi mieć plan - nawet jeśli są to tylko proste dokumenty. Dzięki nim nie zgubimy się w natłoku pracy i nie stracimy informacji, które obszary aplikacji zostały przetestowane, a które wymagają dalszej uwagi.
Na szczęście szczegółowo opisane testy to niejedyne skuteczne narzędzie. Klasyczne, niskopoziomowe (drobiazgowo zdefiniowane) przypadki można śmiało zastąpić wysokopoziomowymi. Zamiast warunków wstępnych, kroków do wykonania czy oczekiwanych rezultatów, tester otrzymuje do rąk wyłącznie hasło - test logowania. To od niego zależy, jakich kombinacji pól logowania użyje (pusty login, puste hasło i tak dalej) oraz jakie komunikaty aplikacji uzna za zrozumiałe dla użytkownika. Jasne, nie mamy tu pewności, że funkcjonalność została przetestowana poprawnie, ale taki wysokopoziomowy przypadek testowy można rozbudować i tym samym sprawić, że wynik testu będzie przejrzysty dla pozostałych członków zespołu.
TODO - lista rzeczy do przetestowania
Listy TODO, checklisty towarzyszą nam w codziennym życiu - choćby na zakupach. Prosta lista rzeczy do wykonania może być też z powodzeniem użyta do zadbania o jakość oprogramowania. Uzupełnienie wysokopoziomowego przypadku testowego o listę przetestowanych funkcjonalności daje już niezły pogląd na pracę wykonaną przez testera. Zamiast komentarza w stylu "jest ok, wszystko działa" otrzymujemy proste podsumowanie sprawdzonych obszarów aplikacji - a jeśli w podsumowaniu czegoś brakuje, to zespół może szybko zareagować.
Powyższy przykład pokazuje checklistę z kluczowymi obszarami prostego sklepu internetowego. Oczywiście, tu również musimy zaufać testerowi, bo przecież nie wiemy, co dokładnie przetestował w sortowaniu produktów. Do punktów zaznaczonych na czerwono należałoby dodać też opis wykrytych problemów. Wspomnę jeszcze, że formą prostego planu testów może być również mapa myśli:
Nie ukrywam, że klasyczne przypadki testowe dają nieporównywalnie większy pogląd na pracę testera i przetestowane funkcjonalności. Nie zmienia to jednak faktu, że powyższe przykłady pozwalają zaoszczędzić mnóstwo czasu. Jestem więc zdania, że (jeśli nasz czas jest mocno ograniczony) lepiej oprzeć się na prostych raportach i planach testowych niż podążać całkowicie na ślepo.
Wyżyny kreatywności
Odejście od klasycznych przypadków testowych daje też pośrednie (z początku niezauważalne) korzyści. Brak szczegółowego planu wymusza na testerach wydobycie pokładów kreatywności. Nie ma tu miejsca dla (brzydko mówiąc) "klikaczy" sztywno podążających za przygotowanymi wcześniej wskazówkami. Do pracy trzeba usiąść z otwartą głową, bo każde testy muszą być poprzedzone samodzielną analizą. To od nas zależy, jakie ścieżki obierzemy w testowaniu danej funkcjonalności. Jest to proces niezwykle rozwijający i stawiający nowe wyzwania każdego dnia.
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
