Napisałem swego czasu felieton ''Komentując komentarze'' (CW 31/03), w którym proponowałem stworzenie katalogu przesądów informatycznych. Wtedy odniosłem się do powszechnego przekonania o niezbędności komentarzy i postawiłem tezę, że dobry program uwag "na boku" praktycznie nie wymaga, a ich pojawienie się jest oznaką niedojrzałości języka programowania, niedostatków w projekcie albo generalnie słabych umiejętności autora kodu.

Dziś chciałbym odnieść się do kwestii testowania. Bezpośrednią inspiracją jest przykład z przemysłu. Otóż rozmawiałem niedawno z pracownikiem działu jakości fabryki samochodów. Opowiadał, że auto schodzące z linii produkcyjnej testowane jest dwa razy, przez ok. 5 minut. Jeżeli nie przejdzie jakiegoś testu, podejmowana jest jedna próba naprawy. Jeżeli przy drugim teście wynik jest negatywny - samochód trafia między dwa potężne zgniatacze, zniszczony egzemplarz wędruje na złom, zaś fabryka wszczyna całą procedurę kontrolną by znaleźć powody, dla których w którejś fazie produkcji zawiodły metody wytwórcze. Co zaś w analogicznej sytuacji robi informatyk? Do upadłego poprawia błędy i modli się, żeby zdążyć na czas.

Oczywiście zdaję sobie sprawę ze słabości porównania przemysłu samochodowego do informatycznego. Natomiast ilekroć słyszę o zaawansowanych narzędziach do testowania i całych społecznościach beta testerów - to myślę sobie, że coś jest nie tak jak trzeba.

Chcę bardzo wyraźnie powiedzieć, że długie i wyszukane testy nie są bynajmniej oznaką dojrzałości procesu wytwórczego i przedsiębiorstwa. Są oznaką słabej jakości pracy całego zespołu - od użytkowników, poprzez analityków i projektantów aż po programistów. Zamiast budować od razu porządne produkty budujemy marne - a potem zatestowujemy się na śmierć.

Wokół testowania wyrósł cały przemysł. Pozwolę sobie na obszerny cytat ze stron firmy, która dostarcza usługę pod nazwą testowanie systemów informatycznych: Każdy błąd ma swoją cenę poprawy. Kiedy poprawiamy błąd w fazie analizy koszt poprawy jest minimalny. (...) Jeżeli ten sam błąd wykryjemy po wdrożeniu systemu to poniesiemy (...) koszt poprawy dokumentu analizy, projektu systemu, ponownej implementacji, testów, złożenia wersji i wdrożenia. (...) Wniosek z powyższego jest jasny - testowanie i wykrywanie błędów się opłaca. Wszystkie założenia i argumentacja są sensowne - tylko wniosek jest absolutnie nielogiczny! Jest właśnie odwrotnie - testowanie to bardzo kosztowny i skrajnie nieopłacalny moment na znalezienie błędów. Najlepiej wykrywać je dużo, dużo wcześniej.

I zaraz potem kolejna bzdura: Skuteczność testów, co nawet nie wymaga formalnego dowodu, zależy m.in. od liczby wykonanych testów. Owo przekonanie jest równie prawdziwe co stwierdzenie, że wiarygodność ankiety zależy od liczby zapytanych osób. Nic podobnego - zależy wyłącznie od reprezentatywności próbki. Analogicznie, skuteczność testów nie zależy od ich intensywności i długości, a od kompletności i wiarygodności warunków, w jakich zostały przeprowadzone.

Miłościwie przemilczę nazwę firmy, która zamieszcza cytowane banialuki na swojej stronie internetowej. Takie myślenie jest, niestety, popularne wśród informatyków. Istnieje powiedzenie, że gdyby domy budowano tak jak konstruuje się programy, jeden dzięcioł zniszczyłby cywilizację. Dołączę jeszcze jedno: gdyby z równie nabożną czcią podchodzono do testowania produktów przemysłowych, samochody zjeżdżałyby z taśmy ze średnio trzema kołami i kierownicą przyczepioną w miejscu czwartego, zaś dopiero po intensywnych testach drogowych przemieszczałoby się ją na właściwe miejsce, a po kolejnej rundzie na oś trafiałoby właściwe koło z oponą.