Krajobraz przed bitwą

Jak powiedział generał, a później prezydent D. Eisenhower, choć planowany przebieg wydarzeń nigdy się nie sprawdza, jednak największe szanse na poradzenie sobie z nagłymi problemami na polu bitwy ma ten dowódca, który planował najstaranniej.

To samo dotyczy testowania. Z prawdopodobieństwem graniczącym z pewnością można przyjąć, że dostawa kodu do testu systemowego będzie opóźniona o dwa miesiące, data dostawy do klienta natomiast się nie zmieni. W efekcie na test systemu, zamiast przewidzianych dziesięciu tygodni, pozostaną zaledwie dwa.

Ponadto wiadomo z góry, że jakość pierwszych wersji będzie taka, iż większość czasu trzeba będzie poświęcić na podnoszenie zawieszającego się systemu, a nie na wykonywanie przypadków testowych.

Rozsądek nakazuje założyć, że znajdowane błędy spowodują nie zaplanowany wzrost liczby dostarczanych do testowania wersji programu, w związku z czym czas poświęcony na ich instalowanie i konfigurowanie oraz na testy regresji dramatycznie wzrośnie. Z praktyki wiadomo że proces "odpluskwiania" kodu (debugging) odciągnie pewną liczbę testerów na pewien czas od testowania. Co więcej, środowisko testowe będzie - w nie zaplanowanych wymiarach czasowych - blokowane przez programistów, usiłujących odtworzyć awarię i zlokalizować jej przyczynę. Tylko wtedy, gdy zaplanujemy, że wydarzy się wszystko to, co nie zostało zaplanowane, mamy szansę poradzić sobie z wyzwaniem, jakim jest zarządzanie testami.

Husaria kontra piechota

Impet w testowaniu jest ważny, jednak jego siła musi być kontrolowana. Od samego początku.

Liczbę wykonywanych przypadków testowych należy porównywać z wielkością zaplanowaną oraz badać ich korelację z pojawianiem się nowych błędów. W ten sposób potencjalne opóźnienie można przewidywać bardzo wcześnie, a nie dopiero wtedy, kiedy narośnie do katastrofalnych rozmiarów.

Śledząc liczbę zgłoszonych błędów, możemy próbować szacować liczbę błędów jeszcze nie odkrytych, które zapewne wyszłyby na jaw w trakcie dalszego testowania systemu. Dzięki temu w każdej chwili mamy do dyspozycji dane, pozwalające odpowiedzieć na nieuniknione pytanie: co kierownik testów sądzi o tym, aby dostawa systemu do klienta odbyła się już pojutrze? Dostrzegając narastające rozbieżności między planem a rzeczywistością, kierownik testów ma do dyspozycji pięć rodzajów środków zaradczych (rys. 1).

• Zmiana harmonogramu testów - odroczenie zakończenia i terminu dostawy do klienta.

• Zmiana kryteriów jakości - obniżenie poprzeczki, dopuszczenie do użytku systemu słabiej przetestowanego albo zawierającego większą liczbę znanych, lecz nie naprawionych błędów.

• Zrównoleglenie prac poprzez zaangażowanie do testowania większej liczby osób.

• Czasowe lub trwałe ograniczenie funkcjonalności systemu.

• Podniesienie wymagań co do jakości oprogramowania dostarczanego do testu systemowego. Przeniesie to ciężar testowania z powrotem na niższe poziomy - testy komponentów i integracyjne.

Gdy liczba zarejestrowanych zgłoszeń błędów gwałtownie wzrasta, często stosowanym zabiegiem jest czasowe zawieszenie wykonywania nowych testów po to, by dać programistom szansę na samodzielne usunięcie jak największej liczby błędów. W tym czasie zespół testowy może poświęcić się wyłącznie testowaniu powtarzalnemu kodu zawierającego kolejne poprawki.

Krajobraz po bitwie

Decyzja o tym, czy można już zakończyć testowanie programu, nie jest decyzją techniczną, lecz biznesową. Stosowana w niektórych firmach zasada, że kierownik testów "podpisuje" zakończenie testów i tym samym niejako własną głową gwarantuje dostateczną jakość produktu, jest absurdem. Tak naprawdę testowanie nigdy się nie kończy. Z podpisem kierownika czy bez niego - zawsze istnieje ryzyko, że w programie pozostały nie zauważone błędy.

Nie znaczy to jednak, że trzeba testować w nieskończoność. Z drugiej strony przecież czai się ryzyko opóźnienia, kar umownych, niezadowolonych klientów, utraty udziałów w rynku na rzecz szybszych czy "odważniejszych" konkurentów. Analiza ryzyka i podjęcie decyzji jest więc zadaniem dla kierownika, a tak naprawdę sponsora projektu ewentualnie dla działu marketingu. Zadaniem zespołu testującego jest natomiast dostarczenie decydentom jak najprecyzyjniejszej informacji do podjęcia tych decyzji.

Istnieje wiele kryteriów szacowania jakości produktu na podstawie rezultatów testów. Pod uwagę są brane np. jaki procent zadań testowych dotychczas wykonano, ile pozostało otwartych (nie rozwiązanych) zgłoszeń błędów itd. Interesującą metodą jest technika oszacowania liczby pozostałych jeszcze w programie, nie znanych błędów na podstawie funkcji najlepiej pasującej do krzywej trendu, wyznaczającej liczbę dotychczas znalezionych błędów. Wyjaśnienie tej metody przedstawia rys. 2. Oczywiście istotność takich oszacowań zależy od liczby i jakości wykonanych testów, które z kolei można mierzyć za pomocą opisywanych w poprzednim artykule miar pokrycia (np. wymagań, funkcji i kodu).