Marnotrawstwo w tworzeniu przypadków testowych

Czy w projekcie informatycznym zdarzyło Wam się tworzyć specyfikację testową do akceptacji oprogramowania przez klienta? Przypadki te w teorii służą do wsparcia całego procesu odbioru i instalacji oprogramowania, i często muszą być bardzo szczegółowe, aby testerzy akceptacyjni, którzy często są użytkownikami danego systemu, byli w stanie zweryfikować wszystkie funkcje. W przyszłości mają posłużyć do utrzymania oprogramowania, ale w praktyce zostaną uruchomione jeden raz i potem przepadną w jakimś repozytorium. 

Przypadek testowy jest tutaj substytutem prawdziwej kontroli jakości. Zakłada się, że skoro coś zostało formalnie zapisane jako weryfikator jakości oraz następnie oznaczone jako ZALICZONY, to znaczy, że system działa. W rzeczywistości jednak przypadki testowe pisane przez firmę tworzącą oprogramowanie koncentrują się jedynie na prostych scenariuszach korzystania z aplikacji, a osoby wykonujące testy nie mają wiedzy o systemie i jedynie ślepo wykonują powierzone im zadanie uruchomienia testów. Nie ma to nic wspólnego z testowaniem i niestety nie potwierdzi, że system nadaje się do wdrożenia. Możemy sobie na własnym projekcie bez problemu policzyć, jakie są koszty związane ze stworzeniem specyfikacji testowej i zestawić z potencjalnymi korzyściami. Poniżej wyliczenie na przykładowym projekcie.

Ile kosztuje przypadek testowy?

Załóżmy, że zamawiający oprogramowanie z sektora publicznego wymaga powstania 5500 przypadków testowych (z prawdziwego przetargu z BIP). Istnieje specyfikacja wymagań (SIWZ), która umożliwia stworzenie takiej liczby przypadków. 
Niech napisanie pojedynczego szczegółowego przypadku testowego z analizą specyfikacji zajmie 20 minut.
Wychodzi na to, że napisanie całej specyfikacji zajmie 110 000 minut, czyli 1833,3 h. Daje to około 11,5 roboczomiesiąca. 
Załóżmy, że analityk lub projektant testów zatrudniony na umowę o pracę zarabia na rękę 5000 PLN miesięcznie, co w dużym uproszczeniu będzie stanowiło około 12000 PLN kosztów pracodawcy (w tym podatki, FP, ubezpieczenia, koszt utrzymania stanowiska pracy, komputer, obsługa HR, powierzchnia biurowa, itd.). Przemnażając koszt pracownika przez pracochłonność wytworzenia specyfikacji otrzymujemy zawrotną kwotę 138 000 PLN za stworzenie specyfikacji. Przypominam, że specyfikacja ta z dużym prawdopodobieństwem zostanie uruchomiona tylko jeden raz i dodatkowo to uruchomienie nie powie nam zbyt wiele o jakości. 

Co w zamian?

Jest kilka rozwiązań, które mogą potwierdzić działanie systemu bez konieczności tworzenia rozbudowanej specyfikacji testowej. Poniżej kilka przykładów.

1. Testowanie w parach

Przedstawiciel klienta siada z testerem i wspólnie przechodzą przez system i specyfikację wymyślając przypadki testowe. Raportowanie może sprowadzać się do notacji wykonanych testów, zaraportowania defektów plus nagrania wideo z przeprowadzonych testów.
 
2. Testowanie eksploracyjne w sesjach

Może być ono wykonane przez testerów akceptacyjnych po krótkim przeszkoleniu. Raport końcowy będzie zawierał wykonane idee testowe, czas poświęcony na testy, zaraportowane defekty. Również tu może pojawić się dowód na przeprowadzenie testów w postaci nagrania wideo lub screencastu.
 
3. Listy kontrolne

Listy kontrolne zamiast opisywać całościowo jak należy zweryfikować daną funkcję, pokazują co należy sprawdzić. Wymaga to od testera akceptacyjnego głębszego poznania systemu, ale może to być część szkolenia do przyszłego jego użytkowania. Raport to odhaczone pozycje na liście kontrolnej oraz raporty z defektów. 

4. Przypadki logiczne zamiast przypadków szczegółowych

Przypadki pozbawione danych testowych oraz oczekiwanych rezultatów są bardziej wymagające do uruchomienia przez testerów akceptacyjnych, ale mogą być uruchamiane w parach.

5. Testowanie akceptacyjne przez zewnętrzny podmiot

Istnieje wiele firm jak nasza, które wykonują na zlecenie klienta akceptację systemu bazującą na specyfikacji wymagań. Nie powstanie tu rozbudowana specyfikacja testowa, ponieważ firma bierze odpowiedzialność za uzyskanie pokrycia i zagwarantowanie pewnego poziomu jakości. 
 
ITP.
 
Odpowiedzialnością testerów oprogramowania jest kontrola jakości, a nie bezsensowne przepalanie godzin (pieniędzy). Wiemy, że „Klient nasz Pan” i jak płaci, to wymaga, ale wejście z nim w dialog daje szansę na uniknięcie marnotrawstwa w testach. Tworzenie bezwartościowej specyfikacji testowej to tylko jeden z wielu potencjalnych kosztów, które możemy wyeliminować poprzez budowanie świadomości tego, co testowanie może dostarczyć. Jeśli tylko uda nam się przekonać klienta, że szczegółowe przypadki testowe nie są mu potrzebne, to za koszt ich stworzenia możemy dostarczyć kontrolę jakości z prawdziwego zdarzenia. 

Grafika: https://pl.freepik.com/racool-studio