181

Testowanie wczesne i częste

143

rada

Jeśli nasz kod nie zostanie dogłębnie przetestowany, to użytkownicy będą napotykać błędy. To nie tylko wprawi nas w zakłopotanie, ale może być też kosztowne. Znajdźmy błędy zanim zrobią to inni. Nie czekajmy z testowaniem do końca cyklu produkcyjnego. Należy testować to, co się da, już w trakcie pisania kodu. Usunięcie niektórych błędów pozwoli uniknąć innych, więc im wcześniej się to zrobi, tym lepiej.

144

Testowanie w niesprzyjających warunkach

rada

Czy kiedykolwiek słyszeliśmy pytanie przyszłego klienta: „Czy to działa na moim komputerze?”. Bo autorzy tej książki tak. Najłatwiej byłoby chyba sprzedać oprogramowanie razem z komputerem, na którym powstało.

Niektóre błędy pojawiają się tylko w wyjątkowych sytuacjach. Należy zatem przeprowadzić testy z małą ilością pamięci, z małą ilością przestrzeni dyskowej, na wolnych komputerach, z błędami w sieci, przy wolnym dostępie do sieci, razem z innymi działającymi aplikacjami, z ogromnymi zbiorami danych. Jeśli używamy wątków, to należy przetestować ich działanie na komputerze z wieloma procesorami. Jeśli kod jest przeznaczony dla serwera, to należy przetestować program przy dużym obciążeniu serwera. Jeśli program odtwarza pliki multimedialne, to należy spróbować go użyć bez karty dźwiękowej itd.

145

Testowanie w skrajnych warunkach

rada

Kod trzeba również przetestować w skrajnych warunkach, które według nas nigdy nie wystąpią. Usunąć pliki, które są potrzebne. Odczytać z uszkodzonej dyskietki. Usunąć dyskietkę w trakcie odczytu. Przekazać do programu niewłaściwe dane. Gdy program żąda podania numeru PESEL — wpisać datę urodzenia. Gdy prosi o podanie wysokości zarobków — wpisać 25 milionów złotych. Gdy prosi o podanie daty — wpisać rok 2001. (To tylko żart. Chyba już nikt nie będzie miał problemów przy przekraczaniu daty 2000.)

Brzmi jak szaleństwo? Takie rzeczy równie dobrze może zrobić nasz klient. Lepiej naprawić błędy, zanim znajdzie je użytkownik.