Czy podczas pracy w projekcie trzeba pisać przypadki testowe?

Cytując Maxa, bohatera jednego z moich ulubionych filmów E=MC2, mogę powiedzieć, że

„nie da się tego teraz tak łatwo wytłumaczyć”,

bo to zależy. Ci z was, którzy mają już trochę doświadczenia zapewne wiedzą, o czym mówię. Wpływ na to ma wiele czynników (wymienionych poniżej) i kontekst, w jakim przyjdzie wam pracować. To samo tyczyć się może innych dokumentów testerskich, jak Test Plan czy Test Raport.

Co ma wpływ na naszą pracę?

• organizacja, w której pracujesz – możesz spotkać się z sytuacją, w której twoja firma będzie miała zdefiniowane Test Policy, Test Strategy albo ogólny Proces Testowy. Z tych dokumentów może wynikać, że przypadki testowe powinny być przygotowywane.
• klient, dla którego projekt jest realizowany – sam klient też czasami wymaga dostarczania pewnej dokumentacji związanej z testami. Powody bywają różne: od braku zaufania do naszych testów po konieczność dokumentowania całego procesu wytwarzania oprogramowania. Może być to podyktowane potrzebami jego klientów lub audytów związanych z certyfikacją. Czasami warto przypadki przygotować jako dowód tego co zostało zrobione, na wypadek gdyby klient powiedział „sprawdzam!”.
• czas trwania projektu – gdy masz do czynienia z krótkim projektem, to może nie być czasu ani sensu inwestować w przypadki testowe. W takim wypadku lepiej skupić się na testach eksploracyjnych, niż tracić cenne godziny na dokumentowanie każdego kroku. Dla dłuższych projektów warto zdefiniować sobie chociażby regresję lub inne powtarzalne testy. Przygotowane przypadki mogą też być bazą do ich automatyzacji.
• wiek testowanego systemu – możesz mieć okazję (tak jak ja kiedyś) pracować ze starym systemem tzw. legacy, gdzie jedyną dostępną dokumentacją jest kod aplikacji, a wiedza na temat poszczególnych funkcjonalności bywa mocno ograniczona. W takim przypadku zdobycie informacji na temat tego, jak coś działa i jak to przetestować, jest bardzo czasochłonne. Warto, by ten wysiłek nie poszedł na marne i udokumentować jego rezultaty np. w postaci przypadków testowych, wiki lub testów automatycznych.
• metodyki, w której projekt jest realizowany – jeśli masz do czynienia z pracą w sprintach, które kończą się sukcesem, to na początku kolejnego powinieneś mieć wolną chwilę zanim dostaniesz coś nowego do testów. Ten czas można wykorzystać na przygotowanie test casów lub napisanie testów automatycznych.
• twojego doświadczenia – sam dobrze wiesz, czego potrzebujesz, by twoja praca była efektywna. Przypadki testowe mogą pomóc dostarczyć zainteresowanym osobom potrzebne informacje na temat testowanej aplikacji. Na ich bazie można przygotować metryki pokazujące np. ilość planowanych i wykonanych test casów, ilość tych, które zakończyły się sukcesem i tych, które nie przeszły. Takie metryki mogą być przygotowane dla całej wersji aplikacji lub poszczególnych funkcjonalności lub wymagania.

Czy zatem warto pisać przypadki testowe?

Podsumowując, to czy i jaką dokumentację będziesz przygotowywać może być narzucone lub zależeć od ciebie, ale bardzo silnie zależy od kontekstu. Jest to zdecydowanie dobra metoda na spisanie zdobytej wiedzy na temat testowanej aplikacji. Może też pomóc w rozpoczęciu automatyzacji, bo będziecie mieć już opisane scenariusze, które można później oskryptować.

W ten sposób udokumentujesz też testy, które wykonałeś. Możesz wykorzystać tę dokumentację jako dowód, gdy później coś się wysypie. Przypadki testowe mogą też się przydać w procesie wprowadzania nowych członków zespołu do projektu lub gdy będziesz potrzebować chwilowego wsparcia, np. podczas regresji. Jeśli nikt nie narzuca konkretnej formy dokumentacji, to warto rozważyć mapy myśli, które bardzo fajnie się sprawdzają.

A jakie jest twoje zdanie na temat przydatności test casów?