Testowanie było, jest i, należy się spodziewać, będzie w dającej się przewidzieć przyszłości nieodłącznym składnikiem procesu tworzenia oprogramowania. Jego udział w tym procesie może sięgać 50% kosztów (wg Systems Testing & Quality Assurance Techniques, Advanced Information Technologies) i ma tendencję do zwiększania się raczej niż zmniejszania.

Oczywiście, brak właściwego testowania pociąga za sobą koszty wielokrotnie większe. Nic zatem dziwnego, że trudno w środowisku osób zajmujących się zawodowo informatyką spotkać kogoś, kto nie uznawałby kluczowej roli testowania dla sukcesu projektu informatycznego. Jeśli nawet są ludzie, którzy nie podzielają tego przekonania, nie przyznają się do tego głośno. Mogłoby się zatem wydawać, że w codziennej praktyce szefowie projektów nigdy nie zaniedbają poświęcenia testowaniu dostatecznej uwagi, a członkowie zespołów zawsze będą traktować wynikłe stąd powinności z najwyższą powagą. Można by sądzić, że projekty, w których kodowanie zajmuje 90% czasu, analiza wymagań i projektowanie są krótką chwilą niezbyt głębokiej refleksji poprzedzającej kodowanie, a testowanie sprowadza się do poddania uzyskanego produktu kilku prostym próbom (byle tylko nie wykryć jakiegoś paskudnego błędu i nie narobić sobie kłopotu z jego usuwaniem), zdarzają się tylko zaliczającym przedmioty studentom informatyki.

Tymczasem sytuacja, chociaż nie jest tak zła, jak to z celową przesadą przedstawiliśmy, pozostawia wiele do życzenia. I o ile z satysfakcją trzeba stwierdzić, że systematyczne podejście do tworzenia projektów informatycznych wyraźnie się w Polsce upowszechnia, w przypadku testowania wydaje się, że mamy do czynienia z niebezpiecznym opóźnieniem, którego szkodliwe skutki w wielu przypadkach dały o sobie znać z całą dotkliwością.

Klient/serwer: nowe możliwości, nowe wyzwania

O ile testowanie zawsze było niezwykle ważne, wraz z nastaniem architektury klient/serwer jako dominującego podejścia do tworzenia biznesowych systemów informatycznych, jego rola stała się jeszcze bardziej krytyczna.

Architektura ta dostarczyła wielu nowych i ekscytujących możliwości tworzenia systemów na miarę szybciej rosnących potrzeb w piątej dekadzie rozwoju informatyki. Czas jednak w końcu przyznać, że oferując atrakcyjną perspektywę tworzenia w metodyczny sposób systemów efektywnie wspomagających zarządzanie organizacją oraz zwiększających wydajność pracy i satysfakcję jej członków, przyniosła ona jednocześnie nowe wyzwania.

Architektura klient/serwer najeżyła drogę ku obiecywanym przez siebie korzyściom rafami nowych zagrożeń, którym przeciwdziałać można jedynie traktując testowanie bardziej niż kiedykolwiek serio. Co więcej, czas sobie uświadomić, że nasze doświadczenia z testowaniem tradycyjnych aplikacji przenoszą się na ten nowy grunt tylko częściowo i konieczne są nowe procedury postępowania. Wynika to z kilku przyczyn, których przegląd zaczniemy od zewnętrznej wartwy systemu.

Warstwa główna systemu typu klient/serwer to kliencka aplikacja sterowana przez użytkownika za pomocą graficznego interfejsu użytkownika (GUI). Już nie projektant z programistą ustalają możliwe scenariusze współpracy użytkownika z systemem, lecz wyobraźnia i upodobania tego ostatniego, który korzystając z różnych elementów GUI niemal bez ograniczeń generować może różne sekwencje zdarzeń, które aplikacja musi odpowiednio obsłużyć. Przyjęty dla tworzenia interfejsów użytkownika styl programowania sterowanego zdarzeniami świetnie się nadaje do spełnienia tych wymagań, ale siłą rzeczy czyni zachowanie systemu znacznie mniej przewidywalnym niż przy tradycyjnym (do niedawna) podejściu. Powoduje to dwa ściśle ze sobą związane skutki: ryzyko pojawienia się w aplikacji błędów istotnie wzrasta, zaś jej wyczerpujące przetestowanie staje się znacznie trudniejsze.

W systemach klient/serwer, oprócz bazy danych i graficznej warstwy prezentacji, jest parę innych ważnych elementów. Jeśli nie szukamy kłopotów, elementy te, o ile nasz system nie jest wyjątkowo prosty i mały, umieszczamy w środkowej warstwie (stąd architektura trójwarstwowa). W typowym przypadku mamy do czynienia z wieloma aplikacjami klienckimi, prawdopodobnie kilkoma serwerami danych i pewną liczbą tzw. serwerów aplikacji w warstwie środkowej. Komunikacja w tak rozproszonym (nawet jeśli wszystko działa na jednym komputerze) środowisku przetwarzania niesie ze sobą ryzyko trudnych do wykrycia błędów.

Wreszcie, jeśli dziedzina zastosowania jest nietrywialna, a zakres odpowiedzialności systemu spory, logika przetwarzania jest sama w sobie złożona. Jeśli wziąć pod uwagę, że jest ona w dodatku na ogół rozproszona (powiedzmy, pomiędzy aplikacje klienckie, serwery lokalne, serwer mainframe), staje się jasne, że przygotowanie właściwej strategii testowania i jej realizacja może być zadaniem bardzo trudnym.

Poza powyższymi, można jeszcze dodać jeden szczególnie znaczący argument: dotychczasowe doświadczenia we wdrażaniu systemów klient/serwer. Według danych Software Productivity Research, błędy w takich systemach pojawiają się o ok. 10% częściej, niż w tradycyjnych systemach opartych na mainframe, zaś liczba błędów w systemach oddanych do użytku jest średnio prawie większa dwukrotnie. Trudno o bardziej dobitny sygnał palącej konieczności upowszechnienie metod systematycznego testowania opracowanych dla architektury klient/serwer, a także komputerowych narzędzi umożliwiających jego automatyzację.