Dzisiaj chciałabym Wam coś opowiedzieć o pisaniu przypadków testowych. W swojej pracy często spotkałam się sytuacją gdzie programiści często nie wiedzieli po co tak naprawdę QA piszą przypadki testowe. Nie widzieli sensu i korzyści a to błąd ponieważ test casy mogą przydać się zarówno QA jak i programistom.
Postaram się też odpowiedzieć na częste pytania związane z przypadkami testowymi: – Co to są przypadki testowe? – Jak napisać dobry przypadek testowy? Co powinien zawierać? – Po co QA piszą przypadki testowe? – Czy liczy się ilość czy jakość? – Jak to ma się do bycia Agile?
Przypadek testowy – czym to się je?
Zacznijmy standardowo od definicji ISTQB, która opisuje przypadek testowy jako “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.”
Teoria nie zawsze dobrze obrazuje efekt końcowy, dlatego lepiej zobaczyć jak to wygląda w praktyce?
Każdy przypadek testowy powinien mieć zdefiniowany:
- unikalny numer
- tytuł
- warunki wstępne
- kroki
- spodziewane wyniki
Forma zwykle jest dowolna, ważna jest czytelność. QA zwykle używają dedykowanych narzędzi do pisania przypadków testowych, które ułatwiają zarządzanie testami, ale są firmy, projekty gdzie przypadki testowe przechowuje się np. w Excelu.
Przypadek testowy powinien opisywać konkretne, oczekiwane działanie programu.
To jak w końcu napisać scenariusz testowy?
Poniżej znajduje się prosty przykład dla dwóch przypadków logowania:
Przypadek 1:
ID: TC_1
Tytuł: Logowanie się do aplikacji z użyciem poprawnego loginu i hasła
Warunki wstępne: W systemie istnieje użytkownik, username: user z odpowiadającym hasłem: pass
Kroki:
1. Otwórz panel logowania
2. Wprowadź poprawną nazwę użytkownika: user
3. Wprowadź poprawne hasło dla użytkownika: pass
Oczekiwnay rezultat:
– użytkownik został poprawnie zalogowany
– główna strona aplikacji została wyświetlona
Przypadek 2:
ID: TC_2
Tytuł: Logowanie się do aplikacji z użyciem niepoprawnego hasła
Warunki wstępne: W systemie istnieje użytkownik, username: user z odpowiadającym hasłem: pass
Kroki:
1. Otwórz panel logowania
2. Wprowadź poprawną nazwę użytkownika: user
3. Wprowadź niepoprawne hasło dla użytkownika: pass2
Oczekiwany rezultat:
– użytkownik nie został zalogowany
– komunikat o błędzie logowania został wyświetlony
– użytkownik nie został przekierowany na główną stronę aplikacji
W podobny sposób możemy rozpisać przypadki testowe na przykład dla okna rejestracji, do zapamiętywania hasła w aplikacji. Tak naprawdę, każda potencjalna akcja użytkownika, mogłaby w ten sposób być opisana. Czy powinna, nad tym zastanowimy się trochę później.
Pisząc przypadki testowe powinniśmy zawsze mieć z tyłu głowy fakt, że inne osoby będą je czytały i wykonywały dlatego też nasze powinny być łatwe do zrozumienia. Osoba, która widzi pierwszy raz napisany przez nas przypadek testowy powinna bez problemów potrafić go wykonać.
Po co nam przypadki testowe?
Dowiedzieliście się już, jak wygląda taki przypadek testowy ale nadal tak naprawdę nie wynika z tego po co je piszemy, skoro funkcjonalności aplikacji są znane i często są opisane w systemie bugtrackingowym.
Wyobraźcie sobie taką sytuację:
Mamy projekt “NaszaApka” gdzie pracuje 3 developerów i 1 QA. QA testuje aplikację ale też dba o stronę biznesową. Wie jak aplikacja ma działać i często programiści pytają QA jak dana funkcjonalność ma działać. Jeśli QA nie jest pewien, dopytuje klienta. Zbliża się deadline. Pewnego dnia w drodze do pracy QA ulega wypadkowi, w konsekwencji czego przez dłuższy czas nie może pracować. Na jego miejsce przychodzi zupełnie obca osoba, nieznająca aplikacji, domeny. Czasu do deadline’u jest bardzo mało. Co robić? Co jest łatwiejsze? Przekopanie się przez setki notek na Jirze i próba wyłuskania z nich wartościowych informacji czy wykonanie zestawu testów?
Wydaje mi się, że lepiej jest mieć najważniejsze przypadki usystematyzowane w jednym miejscu. Takie przypadki zwierają dokładne opisy jak aplikacja ma się zachowywać, dzięki czemu nowa osoba jest w stanie poznać aplikację wykonując testy manualne na podstawie stworzonych przypadków testowych. QA nie może być jedynym silosem wiedzy w projekcie. Oczywiście, bez przypadków testowych zespół zapewne by sobie poradził w tej sytuacji, ale wymagałoby to większego nakładu pracy zarówno ze strony programistów, QA jak i zapewne samego klienta.
Czy spotkaliście się z sytuacją, że specyfikacja wymagań aplikacji jest napisana na dosyć wysokim poziomie uogólnienia? Podczas pisania przypadków testowych, można wyłapać wiele brakujących detali, informacji – których brakuje w dostarczonej dokumentacji. Dlatego też test casy są pisane by uszczegółowić scenariusze wysokiego poziomu i zebrać tą wiedzę w jednym miejscu.
Napisane przypadki testowe są bardzo przydatne przy automatyzacji testów ponieważ mamy dokładnie opisane kroki jakie powinny być zautomatyzowane. Co znacznie oszczędza czas QA.
Pomagają upewnić się że zarówno programiści jak i QA w ten sam sposób rozumieją aplikację. W jednym ze swoich projektów, gdzie było bardzo wielu programistów i kilku QA spotkaliśmy się z sytuacją, że QA miał inną wizję, programista miał swoją wizję tego samego zadania. Wymagania nie były zbyt dobrze sprecyzowane i dużo czasu zajmowały poprawki z tej rozbieżności wynikające. Programiści wiedzieli że QA mają test casy ale nie wiedzieli, że mogą być one również przydatne dla nich.
Wprowadzono w 'Definition of ready’ zapis, że do danej funkcjonalności przypadki testowe muszą być bezwzględnie napisane, zanim programista zacznie nad taskiem pracować. Co więcej, programista musi je przejrzeć i zatwierdzić. Jeśli zarówno developerzy i QA byli zgodni, przystępowano do działania. Jeśli były jakieś wątpliwości – był jeszcze czas by je rozwiać, a same przypadki dopracować. Często pojawiały się dodatkowe pytania. W ten sposób rozwiązano problem tego, że obie strony inaczej rozumiały funkcjonalność. Owszem początkowo sprawdzanie przypadków testowych, spotkało się z dużym oporem programistów, bo przecież zajmuje to ich czas. W praktyce okazało się że już po kilku tygodniach wszystko działało jak sprawnie naoliwiona maszyna. I zarówno programiści jak i QA widzieli w tym korzyść.
Zestaw przypadków testowych często jest dla QA mapą, w którym miejscu testów jest. Co zostało przetestowane a co nie. Co na danym etapie powinno być przetestowane a co nie. W poprzednim artykule (Smoke, sanity i testy regresji) opisałam różne rodzaje testów, w podobny sposóbmożemy stworzyć zbiory przypadków testowych zwanych scenariuszami które będą pokrywały swoim zasięgiem dany typ testów. Np. Mały scenariusz testowy, obejmujący tylko podstawowe funkcjonalności, albo pełny scenariusz testowy zawierający dużą liczbę przypadków testowych. Pierwszy wykonamy na początku iteracji, drugi na jej końcu.
Zapewne gdyby się jeszcze chwilę zastanowić, tych powodów znalazłoby się jeszcze więcej. Przytoczyłam te ponieważ najczęściej z takimi sytuacjami się w swojej karierze spotkałam.
Na podstawie przytoczonych tu sytuacji można odnieść wrażenie że pisanie test case’ów rozwiązuje wiele problemów, jednakże należy zaznaczyć że istnieją pułapki w które bardzo łatwo wpaść…
Jak to w końcu jest? Liczy się ilość czy jakość?
Pisanie a przede wszystkim utrzymywanie przypadków testowych jest bardzo czasochłonne, nie ma co ukrywać. Manualne ich wykonywanie – również. Zatem nasuwa się już pytanie – to ile powinno ich być?
Odpowiem tak – to zależy. Wszystko zależy od projektu w jakim pracujemy i panujących w nim warunków.
W niektórych projektach wręcz koniecznością jest stworzenie obszernego zestawu przypadków testowych, jako część szczegółowego planu z udokumentowanym każdym krokiem. Takie podejście często stosowane jest w projektach długofalowych często sprzężone jest z automatyzacją przypadków testowych.
Inne projekty zaś pozwalają na swobodne podejście do testów gdzie dużą rolę odgrywa testowanie eksploracyjne, gdzie przypadki testowe są ale nie ma ich dużo, są zdecydowanie bardziej ogólne. Z takim podejściem najczęściej spotykamy się w krótkich, małych projektach, gdzie wymagania bardzo szybko się zmieniają i wymagana jest bardzo szybka reakcja. A jeszcze inne projekty wymagają zrównoważenia obu tych podejść.
W takim razie które test casy są ważne a które nie?
Gdy nasze oprogramowanie musi spełniać określone reguły biznesowe wtedy intuicyjnie wiemy, że należy obłożyć je szczególnymi przypadkami testowymi. Mniej krytyczne wymagania można zdecydowanie mniej szczegółowo pokryć przypadkami testowymi. A na końcu możemy pokryć przypadkami testowymi naprawione już błędy, w celu utwierdzenia się że one nie występują.
W ten sposób też określa się priorytety test casów. Są przypadki które powinny być wykonane zawsze, zatem mają wysoki priorytet, a są przypadki testowe, które wykonujemy od czasu do czasu i w zupełności nam ta częstotliwość wystarcza, takie taski mają niski priorytet. To też jest bardzo ważny aspekt. To że mamy duży zbiór przypadków nie oznacza że musimy je wszystkie na raz wykonywać.
Ta priorytetyzacja jest bardzo istotna. Ponieważ można przesadzić i stworzyć ogromną ilość przypadków testowych, których wykonanie i utrzymanie będzie pochłaniało bardzo dużo czasu, a korzyści będą nikłe. Dlaczego? Ponieważ duży zestaw przypadków testowych prawdopodobnie będzie obejmował rzadkie przypadki, które w środowisku produkcyjnym być może nigdy nie wystąpią. Na pełne wyniki testów zespół będzie czekał bardzo długi czas przez co np. krytyczny błąd zostanie wykryty na samym końcu (przy założeniu że testujemy manualnie, chociaż są i projekty gdzie testy automatyczne wykonują się kilka godzin).
Dlatego nie sztuką jest napisać dużo przypadków testowych. Sztuką jest stworzenie takiego zestawu przypadków który nie będzie obciążeniem dla zespołu a wniesie odczuwalną wartość.
A co z byciem Agile?
Zapewne część z Was, czytając ten artykuł pomyślało że test casy to przestarzała forma. Mamy Jirę, jesteśmy agile, szybko reagujemy na zmiany, nie ma czasu na pisanie i utrzymywanie archaizmów.
Jeżeli w projekcie nie ma jeszcze jasnego kształtu aplikacji, jeśli wymagania prawdopodobnie ulegną dużym zmianom to napisanie wielu szczegółowych przypadków testowych jest stratą czasu. Zamiast tego można wybrać stworzenie checklisty i połączyć testy eksploracyjne z prosta listą wymagań zgodności, która nie musi być tak bardzo szczegółowa jak przypadki testowe. A z czasem gdy projekt nabierze określonego kształtu, sytuacja zacznie się stabilizować – można zdecydować się na tworzenie dokładnych przypadków testowych.
Podsumowanie
Pisanie przypadków testowych ma tylu zwolenników ilu przeciwników. Najważniejsze w tym zadaniu jest dostrzeżenie celu i potencjalnych korzyści.
Kluczową rolę pełni tutaj dobre zaplanowanie ilości i rodzaju przypadków testowych. Bo ogromna liczba przypadków testowych nie gwarantuje sukcesu, a mała ich liczba nie zawsze oznacza, że jest ich za mało.
