Powszechny jest nasz autostereotyp, że wszyscy znają się na polityce i medycynie. Nie jestem do końca przekonany czy tylko stereotypem – a nie faktem – jest przeświadczenie światka IT, że wszyscy znają się na testach i testowaniu. Z drugiej strony mojej doświadczenie z różnych projektów podpowiada mi nieustannie pytanie „Skoro tylu się zna to dlaczego tak niewielu potrafi to zrobić poprawnie!?”. I bynajmniej mam tutaj na myśli zarówno aspekt zarządzania, projektowania jak również implementacji testów.
Na pierwszy rzut oka odpowiedź na to pytanie wydaje się prosta; „bo testy to taki bufor czasowy”, „bo testy to dobra praktyka, ale rzeczywistość wymusza co innego”, itd. Z mojego punktu widzenia wygląda to trochę inaczej.
Testowanie z punktu widzenia zarządzania jest to sport dla spadochroniarzy. Z punktu widzenia zaś projektowania i implementacji (wykonanie) jest to dyscyplina przeznaczona dla jednostek specjalnych gdzie liczy się wytrwałość, dokładność szczegółowość oraz doskonałe rozpoznanie terenu.
Mówiąc spadochroniarstwo mam na myśli fakt, że zaplanowanie testów jest możliwe w pełni, kiedy mamy specyfikację lub wymagania zamknięte na jakimś zasadniczym etapie oraz harmonogram całego projektu.
Praktyka, z którą się spotykam w nielicznych przypadkach pozostawia jakikolwiek wpływ kierownikowi testów na termin ostateczny projektu. Jest to jedno z zasadniczych ograniczeń powodujących, że musi on szukać czasu w fazach wcześniejszych a więc musi sobie zapewnić wpływ na kolejność realizacji poszczególnych etapów projektu. Bez wpływu na etapy realizacji lub termin oddania do produkcji jedyne, co pozostaje to maksymalne wykorzystanie dostępnego czasu co oznacza potrzebę zwiększenia ekonomiczności testów (ścisła kontrola nakładów testowych względem testowanego obszaru czyli mówiąc trywialnie mało przypadków testowych testujących możliwie dużo). W tym punkcie związane jest to bezpośrednio z projektowaniem przypadków testowych, o czym pisywałem już wcześniej.
W kwestii projektowania i implementacji ważne jest poznanie produktu, przeanalizowanie jego ekstremów oraz podjęcie decyzji (bardzo często biznesowej) o tym co będzie testowane a co nie. Tak czy siak, testowaną aplikację trzeba atakować systematycznie, ale nigdy metodą szerokiego natarcia. Mnóstwo informacji na ten temat można znaleźć w Internecie i prawie zawsze będą to warstwy interfejsów lub całych przepływów.
Niestety większość kierowników projektów zdaje się nie dostrzegać tej ścisłej relacji czas/kwalifikacje zespołu testów odpychając to argumentem „też kiedyś testowałem”. I rzeczywiście, prawdopodobnie jest to prawdą jednak dłuższy czy krótszy angaż w zespole testów nie stanowi o tym, że jest się testerem lub nie. Znam testerów pracujących jako programiści, integratorzy, architekci a znam też testerów którzy tylko pracują w tym zawodzie.
Przyczyną, dla której użyłem powyżej porównań do wojskowości jest fakt, że testy zdają się „wybuchać” raz po raz. Na początku dla kierownika projektu ważne jest, aby po prostu zrealizować projekt. Walcząc z podstawowymi problemami w projekcie nikt nie zastanawia się nad jakością projektu. Ale nagle, kiedy data finalna projektu jest blisko a sam produkt dobrze rokuje pojawia się problem testowania. „Ktoś przecież musi to przetestować” i tutaj następuje festiwal pomysłów, w którym prym wiedzie kompletna ślepota na ograniczenia czasowe. Ci sami kierownicy projektów którzy z troską pochylali się nad zaplanowaniem poszczególnych zadań w projekcie nagle w stosunku do testów szerokim gestem stosują „czasopodwajacz” i „czasowstrzymywacz” niczym detektyw As oranżadę w „Hydrozagadce”.
W takim ujęciu istotne jest, aby kierownik testów nie tylko pełnił swoją explicite opisaną rolę, lecz również niczym niewolnik powtarzający do swojego wodza „Hominem te memento” powtarzał kierownikowi testów „Testy to też czas i ludzie”.
Reasumując mam wrażenie, że coraz częściej kierownicy testów zmuszani są do walki o uznanie, iż testy są integralnym etapem projektu.
