Miliardy, co z dymem poszły

Przykłady zaniedbań w testowaniu, których powodem była chęć zaoszczędzenia kilkuset tysięcy dolarów, brak kompetencji czy zwykłe niedbalstwo, zaś skutkiem - wielomiliardowe straty - są przygnębiająco liczne. Znamy z własnego, polskiego podwórka np. niedawne kłopoty z systemem informatycznym do obsługi wyborów samorządowych, spowodowane m.in. zaniechaniem testów na obciążenie i przeciążenie.

W skali międzynarodowej wszelkie rekordy pod względem finansowym bije słynna katastrofa rakiety Ariane 5 z 1996 r. , spowodowana błędem przepełnienia bufora. Nie odkryto go, ponieważ nie przetestowano funkcji, która - według popularnego wśród programistów określenia - "przecież dotychczas działała bezbłędnie". Z dymem poszły satelity o wartości kilkudziesięciu miliardów dolarów. Przykłady można mnożyć. Warto zajrzeć w Internecie na stronę profesora Thomasa Huckle'a z monachijskiej politechniki pt. Collection of Software Bugs (http://wwwzenger.informatik.tu-muenchen.de/persons/huckle/bugse.html). Fascynująca, pouczająca, ale i grozę budząca lektura.

Nie trzeba katastrofy

Nawet gdy do "awarii" w popularnym tego słowa znaczeniu nie doszło, gdyż błąd znaleziono i usunięto jeszcze przed wdrożeniem systemu do produkcji, koszty tylko usunięcia błędu mogą znacznie obciążyć budżet projektu i przedsiębiorstwa.

Koszty usunięcia błędu z systemu są tym wyższe, im później w procesie wytwarzania oprogramowania zostanie on wykryty. Usunięcie błędnego zapisu w specyfikacji wymagań kosztuje zwykle zaledwie kilka godzin pracy - przeformułowania tekstu. Ten sam błąd odkryty dopiero w trakcie testu systemowego (jeżeli np. dla "zaoszczędzenia czasu" zaniechano wcześniejszej inspekcji specyfikacji) może wymagać zmian w wielu miejscach kodu źródłowego, a nawet zmiany architektury systemu. To z kolei wymusza konieczność powtórzenia części analiz, testów regresji, przeróbek dokumentacji. Koszty tej operacji mogą bardzo łatwo przekroczyć kwotę, która miała być oszczędzona w wyniku rezygnacji z testów. Jeżeli błędy zosta7ną ujawnione tuż przed terminem oddania systemu do eksploatacji, koszty ich usuwania mogą nawet, z powodu kar umownych, stanowić jej wielokrotność.

Choć to truizm, powtórzmy: opłaca się najpierw myśleć, a potem robić. Testowanie należy zacząć planować już w momencie pisania specyfikacji wymagań. Zastosowanie modelu kaskadowego, zgodnie z którym dwa miesiące przed planowaną datą wprowadzenia programu do użytkowania zaczynają się gorączkowe poszukiwania testerów, to pewna recepta na kłopoty, a już na pewno na wysokie koszty.

Analizy przeprowadzone w rzeczywistych projektach wskazują, że aż 40-60% zgłoszonych awarii ma przyczynę w błędnych, zapomnianych czy niejasno sformułowanych wymaganiach.

Innymi słowy, oszczędny producent, dostawca, właściciel firmy, kierownik projektu mają do dyspozycji tanią, prostą receptę na zmniejszenie kosztów: zatrudnić fachowców od testowania.

Od pierwszego dnia projektu.

Jak to sprzedać?

Aby móc czerpać zyski ze sprzedaży wspaniałego towaru, trzeba najpierw zainwestować pieniądze w jego projekt, konstrukcję i wytworzenie. Kontrola jakości - w tym także i test - również sporo kosztuje, jednak sama z siebie nie tworzy produktów, za które ktokolwiek jest skory zapłacić. To właśnie z tego powodu pokusa oszczędzania na testowaniu jest tak silna i rozpowszechniona. Przekonanie decydentów, że to oszczędność złudna, wcale nie jest łatwe. Posługując się argumentami i słownictwem technicznym, robimy na biznesmenach wrażenie oszołomów, którzy są gotowi zysk poświęcić na ołtarzu jakości, czyli - mówiąc nieco staroświecko - nie rozumieją, że tabakiera jest dla nosa, nie zaś odwrotnie. Z tego właśnie powodu warto mieć w zanadrzu definicje trzech bardzo wartościowych, konkretnych produktów, które test wytwarza:

• Przesłanki do znajdowania błędów. Testując, usiłujemy wywołać awarie systemu, aby umożliwić znalezienie i usunięcie powodujących je błędów; dzięki temu unikamy wystąpienia tych awarii w gotowym produkcie. Wartość tak zdefiniowanego "towaru" jest nie do przecenienia.

• Informacja o ryzyku. Biznes jako taki oraz związane z nim projekty informatyczne są niczym innym jak grą z ryzykiem. Dążąc do absolutnej pewności, że oprogramowanie jest bezbłędne, zbliżamy się zarazem do pewności, iż pewność ta będzie okupiona opóźnieniem i kosztami. Stoimy więc przed dylematem: wdrażać już czy wstrzymać się jeszcze i testować. W każdym przypadku trzeba rozpatrzyć dwa rodzaje ryzyka: techniczne (jakie jest prawdopodobieństwo wystąpienia ważnych awarii w oprogramowaniu dostarczonym jutro i na ile to prawdopodobieństwo można zmniejszyć, testując jeszcze dzień czy tydzień) i rynkowe (jaki może być koszt tygodniowego opóźnienia, co tracimy). Jeżeli testy są wykonywane od początku projektu, ryzyko jest znacznie łatwiej oszacować.

• Informacja o możliwych usprawnieniach. Produktem ubocznym testowania są informacje o tym, gdzie i dlaczego w systemie występują problemy i co należy z tym zrobić. Przykładowo, kłopoty z integracją mogą sugerować, że część zasobów należy przerzucić z testu systemowego na testy modułowe (komponentowe). Jeżeli zaś większość zgłoszonych błędów dotyczy podsystemu X, być może należy przyjrzeć się uważniej warunkom, w jakich jest wytwarzany. Oczywiście, wnioski te można - już po wdrożeniu - kupić od konsultanta w dziedzinie reorganizacji.

Komu bije test?

Nie pytaj, komu bije test. On bije tobie. Niezależnie od wielkości firmy, od złożoności produktu, od wymagań odnośnie do jakości - profesjonalnie wykonany test to źródło zysków, a nie strat. Nie warto więc pytać, "czy", ale "ile" testowania potrzeba oraz jak wykonać je optymalnie i najtaniej.

Bogdan Bereza-Jarociński jest konsultantem w dziedzinie testowania w szwedzkiej firmie Enea. Można się z nim kontaktować pod adresem: [email protected].