Dobór narzędzi testujących nie powinien być kwestią przypadku. Wybór musi być świadomy w trzech płaszczyznach: biznesu, metodyki i technologii.

Idąc do salonu z luksusowymi samochodami, nie przypuszczamy, że sprzedawca najpierw wypyta nas dokładnie o tryb życia, oczekiwania, potrzeby i obyczaje, po czym - być może - zaopiniuje, że zamiast mercedesa raczej powinniśmy sobie kupić tico i małą półciężarówkę. Nie spodziewamy się także, że elegancki i wygadany diler okaże się ekspertem od optymalnych sposobów eksploatacji kosztownej limuzyny, doradzi nam, gdzie - poza drogimi warsztatami firmowymi - można ją będzie naprawiać tanio i dobrze.

Broszury reklamowe wyłożone w sklepie będą wydrukowane na grubym, błyszczącym papierze, pełne szalenie kolorowych i radosnych obrazków podkreślających blaski żywota właściciela luksusowego pojazdu i tysięcznych uciech, jakie oferują nam jego liczne gadżety i efektowne funkcje. Jak poznać, czy naprawdę taka inwestycja nam się opłaci? Co począć, jeśli po pół roku stwierdzimy, że zaiste rację miała wiecznie narzekająca teściowa i lepiej byłoby kupić coś prostszego i ekonomiczniejszego? O tym milczy elokwentny sprzedawca, nie piszą szykowne reklamówki. Wiadomo - takie są reguły gry.

Każdy niby z grubsza wie, do czego służy samochód, i powinien zdawać sobie sprawę, dlaczego woli słyszeć niski, gardłowy pomruk dwuipółlitrowego motoru, zamiast blaszanego chrzęstu ośmiuset centymetrów sześciennych. Metoda sprzedawcy polega m.in. na tym, by wywrzeć swoistą presję na potencjalnego klienta, zagłuszyć jego wątpliwości opowieściami o imponujących detalach technicznych i w końcu stworzyć wrażenie, że wstydem byłoby kupić coś tańszego. Te dobrze sprawdzone mechanizmy handlowe działają nie tylko w salonach samochodowych - blichtr i marzenia sprzedaje także branża informatyczna.

Przez namolność do sukcesu

W szkołach, na uczelniach i licznych zawodowych kursach można się nauczyć programowania, konstruowania architektury systemów informatycznych, kierowania projektami i zarządzania zespołami ludzkimi. Aż dziw, że taki ogrom fachowej wiedzy jakoś nie zawsze owocuje programami, które byłyby robione na czas, bezbłędne i zaspokajałyby rzeczywiste potrzeby klientów i użytkowników. Rzeczywistość firm i projektów informatycznych jest przedmiotem niezliczonych anegdot, jak choćby niezmiernie popularną serią historyjek o Dilbercie. Jasne, że i w innych dziedzinach ludzkiej działalności przekracza się koszty, buduje nie to co trzeba i osiąga solidne opóźnienia, jednak przemysł informatyczny jest pod tym względem niedoścignionym liderem. Dlaczego? Bo brak jest znajomości skutecznych metod produkcji oprogramowania, zaś wiedza z zakresu inżynierii oprogramowania wciąż jest co najwyżej egzotycznym przedmiotem studiów doktoranckich, a nie elementem codzienności.

Wyszkoliłem setki osób, prowadziłem wiele konferencji. W ich trakcie wszyscy zdają się być zgodni, że jakość się opłaca. Potem, niestety, sprawy często toczą się niezmienionym trybem. Dlaczego? Próby prostego oszczędzania pieniędzy przez rezygnowanie z testów czy innych sposobów zapewnienia jakości wszyscy znamy z doświadczenia. Każda złotówka zaoszczędzona na porządnej specyfikacji wymagań, zarządzaniu zmianami czy testowaniu wcześniej czy później spowoduje znacznie wyższe koszty w postaci awarii, utraty zaufania klientów, konieczności przeróbek i ponownych wdrożeń. Czy jednak należy stąd wyciągać absurdalny wniosek, że im więcej wydamy na testy (na przykład), tym tańsza będzie produkcja i wyższy zysk? Oczywiście, nie.

Ocena optymalnego poziomu inwestycji w jakość jest prosta tylko w teorii, w praktyce zaś zwykle niezmiernie trudna. Najłatwiej wyjaśnić to za pomocą ilustracji (rys. 1). Zwiększone nakłady na zapewnienie jakości zawsze powodują zmniejszenie kosztów spowodowanych błędami. Jednak zależność ta nie zawsze jest jednakowo silna. W początkowej fazie zwykle obserwujemy zjawisko, które jest właśnie podstawą twierdzenia, iż rzeczywiście "jakość jest za darmo": spadek kosztów błędów jest znacznie większy niż nakłady na zapewnienie jakości, czyli koszty produkcji (niebieska krzywa na rysunku) maleją. Jednak od pewnego momentu dalsze zwiększanie nakładów na jakość nie powoduje już równie dużego spadku kosztów błędów - "jakość przestaje się opłacać" i koszty produkcji znów idą w górę.

Cała sztuka polega na tym, by znaleźć optymalny poziom nakładów na jakość (na rys. 1 oznaczony gwiazdką). I z tym właśnie jest największy kłopot. Po pierwsze, ten optymalny poziom będzie różny dla różnych typów oprogramowania: inne są np. koszty błędów (głównie koszty awarii) dla oprogramowania sterującego silnikami samolotu pasażerskiego, a inne - dla prostego programu służącego do rejestracji członków lokalnego klubu piłkarskiego. Optymalny poziom inwestycji w jakość będzie oczywiście dramatycznie wyższy dla oprogramowania lotniczego. Trafne oszacowanie kosztów awarii wymaga przede wszystkim dużej wiedzy z dziedziny, której oprogramowanie służy, a niezależnie od tego znajomości zasad marketingu, statystyki i teorii decyzji.

Z kolei ocena tego, na ile określone zwiększenie nakładów na jakość obniży koszty błędów, wymaga dużej wiedzy o metodach zapewniania jakości i skuteczności różnych technik i narzędzi.

Załóżmy, że dodatkowy tydzień testów kosztuje x złotych. Jak obliczyć (czy może zgadnąć?) prawdopodobieństwo, że osiągnięte dzięki niemu obniżenie kosztów błędów będzie większe od x, czyli że inwestycja w ten dodatkowy tydzień się opłaci? I wtedy właśnie niekiedy zjawia się sprzedawca luksusowej limuzyny albo... kombajnu.

Kombajnem przez prerię

Na ścierniskach [...] bogatych gospodarzy stały równymi szeregami opasłe kopy zżętego zboża [...]. Biedniejsi ludzie czekali zazwyczaj na przyjście kombajnów - ogromnych maszyn podobnych do starodawnych mamutów. [...] Mamuty pożerały słomę i wypluwały od razu gotowe ziarno, ale ich robota kosztowała bardzo drogo, ubogim niewiele pozostawało z ich zbiorów. Bogatsi woleli własne snopowiązałki, najmowali ludzi do młocki i dlatego zgodnie z pradawnym porządkiem rzeczy u biednych pozostawało mało, a u bogatych dużo.

Jeśli firma specjalizuje się w produkcji pewnego typu oprogramowania, byłoby rozrzutnością i marnotrawstwem, aby zarazem specjalizowała się w metodykach czy narzędziach wspomagających. Tę lukę kompetencyjną usiłują niekiedy wykorzystywać sprzedawcy samochodów luksusowych lub kombajnów. Jasne, że dla krótkoterminowego sukcesu sprzedawcy może się opłacać przekonanie klienta, że zamiast snopowiązałki potrzebuje kombajnu.