Komu bije test

Testowanie aplikacji, uważane często za nazbyt czasochłonne i kosztowne, już od początku jej wytwarzania przynosi więcej pożytku, niż stwarza problemów.

Testowanie aplikacji, uważane często za nazbyt czasochłonne i kosztowne, już od początku jej wytwarzania przynosi więcej pożytku, niż stwarza problemów.

Pewnej soboty stolarz-amator wziął się do budowy stolika, który miał stanąć na werandzie nowego domu. Za tydzień w domu mieli pojawić się goście. Najpierw gorączkowo gromadził deski, potem było słychać piłowanie, stukot młotka i przekleństwa towarzyszące mozolnemu wyciąganiu źle wbitych gwoździ. Wreszcie zapadła cisza i rozszedł się zapach świeżego lakieru. Potem stuk drzwi, chwila ciszy, wielki huk i znów cały stek przekleństw. Okazało się, że stół jest za duży - na werandzie wprawdzie się mieścił, ale nie sposób było przy nim usiąść, bo na krzesła nie starczało już miejsca.

Słysząc głośne złorzeczenia, na werandzie pojawiła się żona stolarza-amatora. Gdy tylko zobaczyła dzieło męża, zaczęła narzekać: że jest brązowy, ale odcień nie ten, że rogi są ostre, a miały być zaokrąglone, że blat za gruby i przez to zbyt ciężki itd. Awantura trwała do wieczora. Następnego dnia stół trzeba było nieco przyciąć, przeszlifować i pomalować od nowa. Gdy domorosły majster zobaczył wreszcie uśmiech na twarzy żony, był przekonany, że wykonał kawał dobrej roboty. Ona zaś chwaliła się koleżankom, jaki to jej chłop jest zdolny.

Niestety, gdy przyszli pierwsi goście, niespodziewanie wyszło na jaw, że poprzeczki łączące i wzmacniające nogi stołu przeszkadzają w wygodnym siedzeniu, a cała konstrukcja - poza blatem - jest zbyt delikatna i lepiej mocno się nie opierać...

Sąsiad pechowego stolarza zabrał się do rzeczy inaczej: systematycznie i z ołówkiem w ręku.

Najpierw spisał na karteczce życzenia żony, wymierzył werandę, potem zrobił na papierze mały plan, a nawet powycinał małe papierowe modeliki stołu i krzeseł. Wreszcie przyjrzał się innym stołom i krzesłom w domu. Zgrzyt piły rozległ się dość późno. Gdy ucichł, na dłuższy czas zapadła cisza, a później dał się słyszeć szept calówki. Po kolejnej przerwie na werandę wniesiono krzesła. Zapach lakieru czuć było dopiero następnego dnia. Efekt? Pierwsza kolacja przy nowym stole odbyła się dwa dni wcześniej niż u nazbyt porywczego sąsiada-majsterkowicza, stół się nie kołysał i obyło się też bez gorszących kłótni.

Sposób działania pierwszego stolarza przypomina typową sytuację w projekcie, w którym tworzenie kodu jest cenione wyżej niż projektowanie, tworzenie dokumentacji i testowanie. Nawet jeżeli na pozór kod źródłowy jest "substancją" bardziej podatną na ewentualne zmiany niż drewno i gwoździe, to jednak, zważywszy na zwykle większą od stołów złożoność programów, efekt końcowy bywa podobny do tego, który osiągnął pierwszy stolarz.

Praca irytująco powolnego i starannego sąsiada kojarzy się z projektem, w którym pierwsza linijka kodu powstaje wprawdzie względnie późno, za to od początku niemal na pewno jest poprawna. Ponadto, na wszystkich etapach: od rozmowy z żoną począwszy, poprzez robienie planu-makiety, piłowanie, zbijanie i lakierowanie - pojawiają się: sprawdzian, kontrola, weryfikacja, pomiar. I to właśnie jest to, co określamy słowem test.

Gorsze jest lepsze?

Chociaż wszyscy są zgodni co do zasady, że pracę trzeba planować i weryfikować jej efekty po każdym zakończonym etapie, w praktyce większość szefów projektów o tym zapomina. Niestety, stolarz-amator pojawia się w projekcie znacznie częściej niż stolarz-profesjonalista - nawet jeżeli wiadomo że ten drugi jest skuteczniejszy, a produkty jego rąk są lepsze i tańsze zarazem.

W wirze pracy testowanie staje się jedynie "niepotrzebną stratą czasu". Powody takiej sytuacji są często natury psychologicznej: wynik chciałoby się osiągnąć jak najszybciej, najlepiej zaraz. Oczywiście w projektach informatycznych nakłada się na to czynnik finansowy: skoro klient żąda produktu już, zaraz, "na wczoraj" i tylko w takim przypadku gotów jest dobrze zapłacić, cóż począć?

Wydaje się oczywiste, że rezygnując z czasochłonnego konstruowania i walidacji wymagań oraz równie czasochłonnych testów, oszczędzimy na czasie. Prawda: czasem (ale nie często) się uda. Cóż z tego, że nowy system trochę za słaby, trochę za mały, trochę w ogóle nie taki, a koszty jego utrzymania, nieustannych przeróbek (nie mówiąc już o wygodzie użytkowników) na pewno wielokrotnie przekroczą "oszczędności" poczynione w trakcie projektu. Te pieniądze idą już zwykle z innego budżetu, a kierownik projektu zbiera pochwały.

Poza wszystkim już jakoś tak jest, że większość ludzi woli piłować, stukać młotkiem i machać pędzlem, niż pytać o zdanie żony, pełzać po podłodze werandy z miarką w ręku i co chwila sprawdzać, czy na pewno przycięło się deskę właściwej długości. Analogicznie prawdziwą frajdą jest dla wielu programowanie, w porównaniu z którym kontrola jakości i testowanie to zajęcia nudne, mozolne i budzące niechęć. No cóż, taki jest nasz balast genetyczny: ta "aktywna bylejakość" okazała się lepszą strategią przetrwania w trwających wiele setek tysięcy lat czasach, gdy lepiej (nie zawsze, ale statystycznie) było rzucić się do ucieczki przed lwem natychmiast i na oślep, niż oddawać się najpierw czasochłonnej analizie sytuacji.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200