182

146

Testowanie z punktu widzenia użytkownika

rada

Zespoły testujące często piszą wiele testów dotyczących konkretnych funkcji. Są one niezwykle ważne dla zagwarantowania, że każda część produktu działa poprawnie. Ale powinno się też przetestować program z punktu widzenia użytkownika. Należy utworzyć scenariusze typowego użycia i przeprowadzić je. Można się natknąć na nieoczekiwane błędy wywołane przez składniki, które się ze sobą nawet nie komunikują albo przez składniki pozostawiające po sobie dane, mające niekorzystny wpływ na pozostałe składniki. Co gorsza, moglibyśmy znaleźć się w sytuacji, w której poszczególne komponenty funkcjonują poprawnie oddzielnie, ale produkt jako całość — nie.

147

Testowanie z innymi aplikacjami

rada

Użytkownicy rzadko uruchamiają tylko jedną aplikację. Czasami błędy pojawiają się wtedy, gdy w tym samym czasie jest uruchomiona inna aplikacja. Na przykład program mógłby działać doskonale w samotności, ale już przy innych uruchomionych programach mógłby nie wczytać nawet programu instalacyjnego. Albo oba programy mogłyby konkurować o komunikaty zegara, kładąc cały system na łopatki.

Za powstałe kłopoty łatwo obwinić inną aplikację. Ale nie chodzi o to, kto popełnił błąd, tylko jak go obejść.

148

Testowanie na wszystkich platformach docelowych

rada

Jeśli piszemy program dla platformy Win32, to należy go przetestować w systemach Win98, Windows NT i Win95. Każdy z nich ma swoje słabości. Możemy po prostu założyć, że kod będzie działał, ale jeśli tego nie sprawdzimy, to nigdy nie dowiemy się, jak jest naprawdę. Program trzeba również przetestować na możliwie największej liczbie komputerów, drukarek i kart graficznych. Będziemy zaskoczeni tym, jak niesamowite mogą być wyniki, które uzyskamy. A jeśli program będzie działać poprawnie, to tym lepiej. Będzie nam się dobrze spało.