Radek Smilgin
Testowanie jest pozyskiwaniem informacji o jakości. Zbieranie informacji odbywa się poprzez kontrolę specyfikacji w projekcie informatycznym, inspekcję kodu źródłowego, czy testy interfejsu użytkownika. Testowanie ma swoją wartość biznesową wszędzie tam, gdzie biznes ceni informację.
Wbrew obiegowym opiniom samo testowanie nie podniesie jakości produktu jaki tworzysz. Co więcej, nie da Ci nawet gwarancji niezawodności. Testowanie, rozumiane jako sprawdzenie danego produktu, będzie jedynie przefiltrowaną i w miarę obiektywną opinią testera oprogramowania na temat jakości. Realnie testowanie (sprawdzenie) leży u podstaw każdego sukcesu biznesowego. Może z pominięciem projektów, w których ktoś miał po prostu dużo szczęścia.
Decyzja o wydaniu oprogramowania na rynek, czy też przekazaniu oprogramowania zlecającemu je klientowi, winna być poprzedzona wielowymiarową weryfikacją poprawności jego działania. Informacje te są zazwyczaj przetwarzane w podprocesach wytwarzania oprogramowania, takich jak zarządzanie defektami, czy zarządzanie zmianą. Mogą być również tłumaczone z języka technicznego na język biznesu osób decyzyjnych. Przetworzenie informacji nie jest prostym równaniem. Jest w nim wiele elementów i aspektów do uwzględnienia. Będzie to, między innymi, ilość awarii możliwych do zaakceptowania przez użytkownika, relacja jakości produktu do jego ceny, wpływ ilości defektów na postrzeganie marki i wiele innych. Testowanie jest zatem prostą czynnością operacyjną polegającą na pozyskaniu podstawowych informacji niezbędnych w procesie podejmowania decyzji biznesowej.
Czy w związku z tym testowanie niesie za sobą jakąś policzalną wartość? Tak. Wyobraźmy sobie pewien doskonały punkt odniesienia. Twój produkt może zostać oceniony przez grupę odbiorców zanim poniosłeś wydatki na jego wytworzenie. Opinia grupy użytkowników będzie tu gwarancją poprawności działania produktu. W takim wypadku dostajesz więc jednoznaczne potwierdzenie, że twój produkt spełnia oczekiwania rynku. Ten przypadek jest niemożliwy do osiągnięcia, więc postawmy go na najwyższym pułapie. Mając punkt maksymalny możemy określić również poziom zerowy. Produkt pojawia się na rynku bez żadnej weryfikacji i konsultacji. Nie sprawdzasz czy rynek go potrzebuje i czy w ogóle działa. Po prostu wydajesz go z zaciśniętymi z całych sił kciukami, zaklinając rzeczywistość. W tym przypadku ponosisz koszty, a szansa na komercyjne powodzenie jest porównywalna z sukcesem, z bajki o dziewczynce z zapałkami.
Im więcej testów czy też sprawdzeń uruchomimy, tym większą pewność powodzenia projektu będziemy mieli. Nie jesteśmy oczywiście w stanie sprawdzić dokładnie wszystkiego. Nigdy też nie będziemy mieli gwarancji poprawności działania. Warto jednak zauważyć, że uruchomienie nawet niewielkiej ilości testów da nam sporo podstawowych informacji. Mogą one być bezpośrednio użyte do podejmowania decyzji, bez konieczności rozbudowanej analizy czy też przetwarzania. Późniejsze testy będą upewniały nas w przekonaniu, że idziemy we właściwym kierunku. Trzeba mieć jednak świadomość, że powyższe będzie poprawnym tokiem rozumowania tylko, jeżeli otrzymane informacje będą użyte do odpowiedniego sterowania rozwojem oprogramowania. Uruchomienie testów, które zakończą się niepowodzeniem, nie da nam (nawet znikomej) gwarancji sukcesu, jeśli informacji tej nie użyjemy do naprawienia problemów.
W arsenale testera oprogramowania pojawia się cały wachlarz testów. Od tych, w których specjalista sprawdzi czy twój pomysł można zaimplementować (feasability study), przez weryfikację kodu, sprawdzenie architektury i funkcji, po końcowe testy z użytkownikami. Po drodze miniesz dziesiątki punktów kontrolnych, związanych z jakością półproduktów i dojdziesz do upragnionego wydania oprogramowania na rynek.
Setki publikacji potwierdzają przytoczone powyżej fakty, np. "The Economic Impacts of Inadequate Infrastructure for Software Testing", wydane przez National Institute of Standards & Technology. Koszty niskiej jakości oprogramowania wynoszą 59,5 miliarda dolarów rocznie, a możliwe oszczędności związane z lepszym testowaniem to 22,2 miliarda dolarów rocznie.
Koszty defektów również pojawiają się w wielu publikacjach, w tym w książce Steva McConnell’a, "Code Complete", wydanej przez Microsoft Press. Pojawia się tu reguła: 1:10:100, która wspominana jest w wielu innych źródłach, m.in. w badaniach IBM, czy w książce "Effective Methods for Software Testing", napisanej przez Williama E. Perry’ego. Reguła ta mówi, że koszt naprawy defektów w specyfikacji, jest jednokrotnością w stosunku do 10-krotnie większego kosztu, gdy ten sam defekt trzeba naprawić po testowaniu i 100-krotnie większy, jeśli naprawiany jest po wydaniu produktu klientowi.
Każdego dnia krajową i międzynarodową prasę obiegają informacje o awariach i ich kosztach. Od luk bezpieczeństwa wykorzystywanych do kradzieży danych i pieniędzy, poprzez wezwania tysięcy samochodów na przegląd po wykryciu usterki, po informacje o olbrzymich kosztach ponoszonych przez administrację państwową na niedziałające lub wadliwe oprogramowania.
Większości problemów z oprogramowaniem można by uniknąć, jeśli tylko odpowiednio szybko i w profesjonalny sposób pozyskamy na jego temat informacje. Testowanie jest źródłem tej wiedzy, ale jest również kosztem. Zrównoważenie wartości biznesowej, wynikającej z testowania i nakładów ponoszonych na pozyskiwanie informacji, jest kluczowym obowiązkiem każdego managera. Wywiązanie się z tego zadania będzie jednoznacznym wskaźnikiem skuteczności i efektywności jego pracy, co z kolei będzie różnoznaczne ze zwiększeniem prawdopodobieństwa osiągniecia biznesowego powodzenia.
Artykuł został opublikowany w 2014 roku na portalu techmine.pl.
