Testowanie gruntowne jest niemożliwe – to pierwsza zasada testowania wg. Sylabusa ISTQB® - kodeksu testera. Muszę się z tym zgodzić, nie da się przetestować wszystkiego od A do Z. Jednak należy zdać sobie sprawę, jak ogromne znaczenie ma proces testowania. Może to zapobiec stratom finansowym, paraliżu systemów informatycznych, a nawet uratować zdrowie i życie.
W codziennym życiu, podczas przeglądania stron internetowych, czy korzystania z systemów informatycznych, możemy napotkać różne drobne usterki spowodowane błędami. Są one dla nas uciążliwe i utrudniają pracę. Można, a nawet warto zgłosić takie zdarzenia do administratora strony, mając w pamięć, jak niepozorne błędy mogą być brzemienne w skutkach.
Do słynnych awarii systemu możemy zaliczyć Millenium bug, kiedy to wiele systemów uległo awarii. W epoce pierwszych komputerów, dla zaoszczędzenia pamięci, rok był zapisywany tylko dwiema ostatnimi cyframi. Pod koniec roku 1999, kiedy data miała zmienić się na 2000 r., obawiano się, że komputery wrócą do daty 01.01.1900 r. Niestety takie przypadki się wydarzyły, ale ich skala nie była tak znamienna, jak przypuszczano. Innym przykładem jest precedens dodania sekundy przestępnej w dniu 30.06.2012 r., który spowodował ogromną awarię wielu serwisów oraz zaowocował atakami hackerskimi na maszyny pracujące w systemie Linux.
Jednak najbardziej znamienne w skutkach były błędy, które spowodowały utratę życia lub zdrowia ludzkiego. Urządzenie Therac-25 było stosowane w latach 80. XX wieku do radioterapii nowotworów. Błędy w oprogramowaniu sterownika spowodowały utratę życia 5-ciu osób. Pacjenci otrzymali dawki promieniowania kilkunastokrotnie większe od zaleconych, co spowodowało u nich chorobę popromienną i śmierć w ogromnym bólu.
Z kolei awaria systemu antyrakietowego Patriot, w trakcie wojny w Iraku kosztowała życie 28 żołnierzy. Okazało się, że komputer celowniczy po 100 godzinach pracy zapętlał się na ok. 0,003 sekundy i czas ten narastał z każdą kolejną godziną. Po kilku dniach błąd urósł do 0,3 sekundy, co wystarczyło, by w kluczowym momencie Patriot nie zareagował poprawnie.
NASA również ma na koncie spektakularne bug’sy. W roku 1962 została wystrzelona na orbitę Wenus rakieta, mająca na celu wzniesienie sondy kosmicznej Mariner 1. Niestety, popełniono błąd w trakcie pracy nad oprogramowaniem, której celem było zabezpieczenie rakiety na wypadek uszkodzenia zewnętrznej anteny odbierającej sygnały z ziemi. Przyczyną katastrofy okazał się myślnik w kodzie. Spowodował, że każda, nawet minimalna, zmiana prędkości była przez program komputerowy traktowana jako priorytetowa, przez co rakieta zaczęła wykonywać szereg gwałtownych ruchów i zboczeń z kursu, najprawdopodobniej w celu dostosowania prędkość. Zdezorientowani Inżynierowie, już w 293 sekundzie po starcie zdecydowali o zniszczeniu rakiety, z nadrzędnym celem bezpieczeństwa.
Inna kosmiczna katastrofa wydarzyła się z 1996 r. Rakieta Europejskiej Agencji Kosmicznej — Ariane 5 wznosiła na orbitę okołoziemską zespół sond do badania magnetosfery. W 37 sekundzie po starcie rakieta nagle przechyliła się o 90°, a siła aerodynamiczna spowodowała oderwanie się napędów rakietowych od reszty konstrukcji. Poskutkowało to uruchomieniem procedury autodestrukcji i eksplozję 4 km nad ziemią. Katastrofę spowodował błąd w kodzie oprogramowania, odpowiadający za określanie pozycji rakiety w układzie współrzędnych. Zmienna, która przechowywała korektę prędkości w osi poziomej, była konwertowana z 64-bitowej liczby przecinkowej na 16-bitową całkowitą. Po osiągnięciu przez zmienną wartości większej niż maksymalna liczba całkowita zapisana na 16 bitach moduł pozycji, zamiast rzeczywistej wartości podawał wartość oznaczającą błąd. Skutkiem niewłaściwej interpretacji była reakcja systemu nawigacji polegająca na korekcie kursu. Operacja spowodowała przeciążenie pamięci i wymuszenie przez system autodestrukcji rakiety. Śledztwo badające przyczyny katastrofy wykazało, że powodem było nieumiejętne skopiowanie części oprogramowania z Ariane 4 oraz nieprzeprowadzenie testów i symulacji komputerowych. Błąd kosztował blisko 10 lat pracy i 7 mld USD.
Warto również wspomnieć przypadek Mars Cilmate Orbiter, który łączy w sobie błąd oprogramowania z problem komunikacyjnym. Sonda, która miała w 1998 r. zbadać panujący na Marsie klimat, weszła w atmosferę Marsa z nadmierną prędkością i po niewłaściwej krzywej. Skutkiem było spłonięcie sondy w atmosferze. Koszt tego błędu to 190 mln dolarów. Śledztwo wykazało, że dwa zespoły programistyczne nie dogadały się ze sobą. Zespół kontroli naziemnej jako jednostki siły używał funtów, natomiast zespół oprogramowania sondy liczył wartości w niutonach.
Opisane powyżej przypadki niosły za sobą ogromne straty. Na szczęście z biegiem rozwoju branży IT, rośnie świadomość, jak niezbędne jest testowanie na wszystkich etapach wytwarzania oprogramowania — od zapoznania się z dokumentacją oraz analizy założeń projektu i pomysłów klienta do testów akceptacyjnych. Przytaczając ponownie vademecum testera, co prawda testowanie gruntowne jest niemożliwe, a przekonanie o braku błędów jest błędem, to zasada, że testowanie pozwala zaoszczędzić czas i pieniądze jest bezkompromisowe.
Joanna Mozolewska-Rajkiewicz (Project Quality Manager, Certyfikowany Tester ISTQB®)