Procentowa liczba błędów w aplikacjach komputerowych nie zmienia się od 15 lat. Jednym z powodów tego zjawiska jest niska jakość metod testowania oprogramowania.

Przyjmuje się, że liczba linii kodu w wykorzystywanych na świecie aplikacjach podwaja się co 18 miesięcy. Jeżeli procentowy udział błędów w nowo tworzonych programach utrzyma się na tym samym poziomie, co obecnie, liczba błędów wykrywanych w oprogramowaniu wzrastać będzie dwukrotnie co półtora roku. Można sobie wyobrazić, że gdy liczba błędów w aplikacji nie przekracza 10, to zlokalizowanie ich i usunięcie jest zadaniem stosunkowo łatwym. Jeżeli jednak w potężnym programie jest ich 1000 czy więcej, wówczas okaże się, że usunięcie błędów przekracza możliwości działu informatycznego w przedsiębiorstwie.

Tymczasem, jak wskazują statystyki, szybkiemu wzrostowi liczby wierszy w nowo tworzonych programach nie towarzyszy, niestety, poprawa jakości testów, jakim są one poddawane. Co za tym idzie, nie poprawia się także jakość komercyjnych wersji oprogramowania. Najbardziej cierpią na tym końcowi użytkownicy - głównie ci, którzy wykorzystują do pracy komputer PC. Jak wykazały bowiem przeprowadzone w ub.r. badania, błędy w oprogramowaniu najczęściej zdarzają się właśnie na w przypadku tego sprzętu.

Oprogramowanie rozrosło się już do ogromnych rozmiarów. Jako przykład mogą służyć aplikacje wykorzystywane chociażby w sprzęcie elektronicznym powszechnego użytku. Sama elektronika w samochodzie jest obsługiwana przez 80 tys. linii kodu w języku C, nie mówiąc już o sprzęcie telewizyjnym, gdzie kod źródłowy liczy ponad 150 tys. linii. Jak więc poradzić sobie z pojawiającą się w niej coraz większą liczbą błędów?

Polubić błędy

Przyzwyczajenie użytkowników do niskiej jakości wykorzystywanego przez nich oprogramowania coraz częściej niekorzystnie wpływa na proces testowania. Osoby odpowiedzialne za proces zwykle działają pod presją czasu, dysponują ograniczonym budżetem. Często pozostają w cieniu programistów tworzących aplikację. Tymczasem odpowiedzialność za wady w działaniu aplikacji i nie spełnione oczekiwania użytkownika spoczywa wlaśnie na osobach zajmujących się testowaniem oprogramowania, a nie na programistach. Jeżeli oprogramowanie jest mało wyszukane, to testujący są w stanie przekazać poprawnie działający program w terminie. Natomiast w przypadku bardziej skomplikowanych aplikacji rzadko się to udaje. Najczęściej kończy się to frustracją zespołu testowego, nie mogącegp wywiązać się należycie ze swoich obowiązków. Jedynym sposobem rozwiązania tego dylematu jest zmiana reguł gry.

Jednym z rozwiązań, jakie przychodzi do głowy, jest rozszerzenie kręgu osób odpowiedzialnych za poprawne działanie tworzonego - wewnętrznymi lub zewnętrznymi siłami - oprogramowania. Przedtem należy jednak odpowiedzieć na pytanie, jak duże środki przedsiębiorstwo jest gotowe przeznaczyć na potrzebne oprogramowanie. Jeśli nie są one tak duże, jak życzyłby sobie główny informatyk przedsiębiorstwa, zwykle pojawia się konieczność zrezygnowania z produktów najwyższej jakości. W tej sytuacji zespół testujący nie powinien badać oprogramowania całościowo, ale tylko w zakresie funkcji bezpośrednio widocznych dla użytkownika, bez których nie uda się uzyskać jego akceptacji. Ważne błędy można wtedy wyeliminować od razu, inne usterki - być może dopiero w następnej wersji.

Oczywiście taki sposób myślenia jest dla wielu głównych informatyków nie do przyjęcia i próbują oni zapewnić wysoką jakość tworzonego oprogramowania w inny sposób. Sedno sprawy tkwi w tym, aby złożony proces tworzenia oprogramowania kontrolować od samego początku poprzez testowanie pojedynczych komponentów, rozkładając tym samym w czasie ujawnianie błędów. Błędy, które wykryto w prawie gotowym produkcie, lub, co gorsza, po rozpoczęciu jego wdrożenia, muszą być przecież usunięte, a to powoduje opóźnienie realizacji projektu i zwiększenie kosztów.

Dlatego plan takiego testowania wraz z konkretną specyfikacją powinien nakładać się na plan rozwoju oprogramowania. Najlepszym środkiem zapobiegawczym jest spisanie założeń systemu, co umożliwia prototypowanie, pozwalające na maksymalne zbliżenie się do wyobrażeń użytkownika. Wszelkie propozycje zmian, zgłoszone przez użytkowników, mogą być na tym etapie projektowania zaakceptowane przez programistów i bez trudu wprowadzone do systemu.

Magia pudełek

W zakresie projektowania i modelowania systemu dostępne są standardowe testy funkcjonalne (typu blacküboxütesting), mogące skontrolować system na wszystkich etapach opracowywania, od początku, aż do końcowej implementacji i integracji. W tym przypadku jednym z najtrudniejszych zadań jest wybór stosownych funkcji i przypadków, w których programy powinny być przetestowane, tak aby przy najmniejszych możliwych nakładach osiągnąć najlepszą jakość. Wyboru najważniejszych funkcji dokonuje się najczęściej metodą punktową, arbitralnie nagradzając kompleksowość, częstotliwość użytkowania, bezpieczeństwo lub przyjazność dla użytkownika. Dobrze przeprowadzona analiza pozwala w tym wypadku na przetestowanie 80ü100% różnych gałęzi programu.

Nie każdego zadowalają jednak funkcjonalne testy "z czarnego pudełka". Część testujących oprogramowanie woli łączyć je z dynamiczną, strukturalną kontrolą. Ten rodzaj testowania, nazywany whiteüboxütesting, rozciąga się aż do poziomu kodu aplikacji. Powodem stosowania tego rodzaju metody jest, potwierdzona badaniami statystycznymi, reguła, że błędy najczęściej pojawiają się w modułach, które mają mniej niż 50 linii, i w komponentach, posiadających mniej niż 250 linii kodu źródłowego, przy czym zagęszczenie liczby błędów każdorazowo zdarza się na początku i na końcu modułów. I to bez względu na to, czy aplikacja została zaprogramowana w asemblerze, C, C++, Fortranie czy Cobolu. Dynamiczne wykorzystanie informacji przez testujących może znacznie zwiększyć ich wydajność i efektywność.

Kosztowne testowanie

W przeciętnym amerykańskim ośrodku informatycznym zespół zajmujący się testami i specyfikacją oprogramowania stanowi mniej więcej 10% jego personelu. W Polsce większość przedsiębiorstw w ogóle nie ma takich komórek, powołując je ad hoc w przypadku np. rozstrzygania przetargu na kompleksową informatyzację.

"Nie musimy przeprowadzać żadnych testów, bo nasze oprogramowanie działa na mainframie" - odpowiedział nam jeden z głównych informatyków w polskiej firmie na pytanie, czy dysponuje zespołem testowym. W wielu przypadkach panuje przekonanie, że obecność w komórkach informatycznych ludzi wyspecjalizowanych w procesie testowania oprogramowania jest zbędna. Najczęściej aplikację testują sami jej twórcy. Jak potwierdzają główni informatycy, ci tzw. guru, często kiepsko opłacani, z reguły kodują aplikację użytkową bez projektu, dokumentacji, wsparcia zespołu i bliskiego kontaktu z użytkownikami. W przypadku niepowodzenia zmieniają pracę. Taki scenariusz nie przewiduje oczywiście poprawnego testowania aplikacji, a błędy są wykrywane dopiero "na żywym organizmie", co powoduje w późniejszej eksploatacji wiele nerwowości.

Testowanie oprogramowania jest wprawdzie kosztowne, ale - jak wynika z badań brytyjskiej firmy konsultingowej Grove Consultants - proces ten charakteryzuje się wysoką stopą zwrotu inwestycji (nawet do 300%). Największe koszty są ponoszone, wtedy gdy do lokalizacji błędów w oprogramowaniu przystępuje się dopiero na etapie wdrożenia, najmniejsze - gdy zainwestuje się w profilaktykę. "Testy stanowią najlepsze zabezpieczenie jakości, umożliwiają uniknięcie lub wykrycie we wczesnym stadium wielu błędów. Proces ten opiera się na współpracy między zespołem testowym a programistycznym. Aby jednak do tej współpracy doszło, trzeba wyraźnie oddzielić kompetencje obu grup i wygospodarować, szczególnie na tę pierwszą, oddzielne środki z budżetu. A nie jest to wcale proste" - twierdzi główny informatyk w jednym z polskich banków, proszący o zachowanie anonimowości.

Aplikacje użytkowe a rok 2000

Na wzrost zainteresowania testowaniem oprogramowania nie trzeba będzie długo czekać. Reforma europejskiego systemu walutowego oraz operacji rachunkowych, związana ze zmianą tysiąclecia, wymusi bowiem rewizję dotychczas użytkowanych aplikacji oraz skłoni do zapewnienia im odpowiedniej konserwacji i opieki.

Większość stosowanych na świecie aplikacji (ok. 82%) jest oparta na modelu centrycznym i pozostaje za systemami klient/serwer 2ü3 generacje z tyłu. Dopóki oprogramowanie to jest "zamrożone", opieka nad nim nie sprawia problemu. Jednak oprogramowanie, nawet to użytkowane od lat, rzadko kiedy nie zmienia się. Badania statystyczne dowodzą, że każdy program doznaje rocznie 5-10% poprawek swojej zawartości. Co 6 miesięcy, a w niektórych przedsiębiorstwach nawet co kwartał, ośrodek informatyczny musi tworzyć kolejną wersję oprogramowania, które 2ü4 razy rocznie powinno przechodzić standardowe procedury testowe. Dokładne testowanie z reguły nie jest możliwe, gdyż często brak jest dokumentacji systemu, a nawet kodu źródłowego niektórych z modułów.

Wszystkie wymienione problemy nasilą się w miarę zbliżania się przełomu tysiącleci. Można spodziewać się, że w roku 2000 wiele używanych do tej pory podprogramów, adresów pamięci, parametrów zarówno wejściowych, jak i wyjściowych oraz algorytmów nie będzie mogło ze sobą poprawnie współpracować. Zdaniem specjalistów, dopiero wtedy użytkownicy docenią znaczenie testów.

Automatyzacja testowania

Wzrost zapotrzebowania na usługi związane z testowaniem oprogramowania zaowocował pojawieniem się na rynku wielu narzędzi wspomagających to zadanie w sposób automatyczny (tzw. CAST - Computer Aided Software Testing). Tylko w elektronicznym katalogu angielskiej firmy London CMI Ltd ([email protected]) można ich znaleźć ponad 150. Produkty typu CAST można podzielić na kilka kategorii.

Do pierwszej należą narzędzia do wspomagania zarządzania testami. Do drugiej - narzędzia do logicznego i fizycznego (np. w zakresie implementacji baz danych) testowania projektów. Oprócz tego można znaleźć także narzędzia do statycznej i dynamicznej analizy zachowania aplikacji, jak i do testowania jakości samych testów.

Najbardziej popularnym narzędziem typu CAST jest debugger (odpluskwiacz). Oprócz niego na rynku dostępne są również narzędzia do testowania przepływu czynności, wydajności i obciążenia systemu komputerowego, jak i do symulacji oraz testowania migracji danych. Nie można także zapomnieć o narzędziach typu defect tracking - do rejestracji wykrytych i usuniętych błędów oraz captureüreplay do utrwalania i analizowania wszelkich działań użytkowników, mających wpływ na funkcjonowanie systemu.

Testy to nie wszystko

"Najpierw idzie wszystko dobrze. Potem nagle, w czasie testów, pojawia się chaos. Nic nie idzie, tak jak powinno" - twierdzi jeden z głównych informatyków, który próbował wdrożyć u siebie procedury testowe. Wyniki niektórych badań wskazują, że same testy nie gwarantują pomyślnej realizacji wdrożenia projektu. Podkreślają, że nie mniej ważnym czynnikiem jest stworzenie odpowiedniego klimatu organizacyjnego i właściwych stosunków międzyludzkich między zespołem programistów i testujących.

Za każdym razem, gdy rozpoczyna się wdrożenie projektu informatycznego, nie ulega wątpliwości, że ktoś na nim skorzysta, a ktoś inny straci - np. struktura centralna na rzecz zdecentralizowanej. Pokonany, utraciwszy wpływy, jest wrogiem nowego systemu i w konsekwencji - ośrodka informatyki, który zaprojektował specyfikację użytkowania systemu. Przy inwestowaniu w centrum testowe oprogramowania nie można zapomnieć, że wszystko zaczyna się od ludzi i od konfliktu interesów. Jeśli uda się je pogodzić, oprogramowanie będzie stworzone szybciej i bez błędów.