Rational (obecnie IBM) w swoich produktach zaimplementował większość wzorców tzw. Gang of Four (nazwa pochodzi od czterech autorów książki uznawanej za biblię wzorców). Projektant może natychmiast wstawiać do modelu gotowe wzorce. Jednocześnie narzędzia XDE i Rational Rose mogą identyfikować wzorce wewnątrz modelu, wykrywając charakterystyczne struktury obiektowe.

Testowanie i projektowanie interakcji usług Web

Pisząc o testowaniu, warto wspomnieć o nowych elementach, jakie pojawiają się wraz z wdrażaniem systemu wykorzystującego usługi Web (usługa Web to sposób zdalnego wywoływania funkcji za pośrednictwem protokołów internetowych HTTP/XML/SOAP; analogią jest formularz na stronie HTML, gdzie wpisujemy dane, po czym za chwilę otrzymujemy np. wynik wyszukiwania). Na bezpieczeństwo usług Web wpływają dwa czynniki. Pierwszy jest związany z naturą tych usług. Zwykle są one udostępniane wszystkim zainteresowanym i przez to, podobnie jak strony WWW, są narażone na ataki DoS i duże obciążenie itp. Drugi jest związany z tym, że usługi Web, tak jak tradycyjne programy, są wrażliwe na zmiany funkcjonalne.

Praktycznie narzędzia do testowania usług Web mogą być podobne do używanych przy testowaniu witryn WWW. Tak samo można badać skalowalność rozwiązania, średni czas oczekiwania na wynik itp. Obecnie w większości języków i środowisk IDE nie ma dużej różnicy pomiędzy funkcją w programie a zdalną usługą Web - usługę wywołuje się w ten sam sposób, co najwyżej ręcznie konstruując odpowiedni element pośredni.

Jednym z celów, dla których powstały usługi Web, było ułatwienie integracji różnych systemów informatycznych. Zdarza się więc, że projektant systemu staje przed zadaniem właściwego obsłużenia "zewnętrznej" usługi Web, o której wie niewiele ponad to, co wynika z dostępnej specyfikacji. Nie jest to problem natury technicznej, protokoły obsługujące usługi Web są bowiem w dużym stopniu ustandaryzowane - "każda usługa dogada się z każdą", bez względu na platformę, system czy język programowania. Problemem jest zaufanie, jakim obdarza się autora publicznie dostępnej usługi Web. Jeśli napisana przez niego aplikacja obsługująca usługę Web ma błędy, może to powodować wiele komplikacji.

Narzędzia

Testowanie jest żmudne, czasochłonne i kosztowne. Dodatkowo - w odbiorze wielu osób - tester, zupełnie niezasłużenie, stoi znacznie niżej w hierarchii niż programista-analityk-developer. Tymczasem, aby efektywnie testować aplikację, po pierwsze trzeba umieć zaprojektować zestaw testów (co zwykle wiąże się z zakodowaniem odpowiedniej funkcjonalności), po drugie, umieć czytać obcy kod i na podstawie specyfikacji funkcjonalnej produktu przewidywać, co należy testować. Należy bowiem podkreślić, że co prawda dobrą miarą stopnia przetestowania jest np. tzw. miara pokrycia kodu testami (structural coverage), która określa, ile razy dana instrukcja była testowana, ale miara ta nie daje informacji o testowaniu interakcji poszczególnych modułów. Tymczasem większość błędów (poza błędami związanymi z bezpieczeństwem) wynika z tego, że jakaś funkcja nieprawidłowo działa, ale tylko wtedy gdy ją wywołuje konkretny moduł. By to przewidzieć, potrzebne jest doświadczenie testera i dobre narzędzia, które ułatwią mu pracę. Przetestowanie każdej możliwej kombinacji jest po prostu niemożliwe.

Praktycznie narzędzia do wspomagania testowania można podzielić na kilka kategorii. Do testów użytkowych służą aplikacje, które symulują pracę użytkownika. Tester nagrywa "operacje" wykonywane przez użytkownika, parametryzuje skrypty (np. w taki sposób, by dane były pobierane z bazy), po czym uruchamia test, sprawdzając, czy skompilowany program działa prawidłowo. W ten sposób kontrolowana jest funkcjonalność aplikacji z poziomu użytkownika. Do tego typu aplikacji należy WinRunner, XRunner (Mercury Interactive), QARun (Compuware) czy prosty Tasker. Dzięki umiejętnemu "nagraniu" i zmodyfikowaniu skryptów, można wraz z każdą kompilacją sprawdzić, czy jest zachowana właściwa funkcjonalność aplikacji. Podobne rozwiązania istnieją dla aplikacji opartych na WWW.

Jednak samo testowanie funkcjonalne nie wystarczy. Bardzo ważne są tzw. narzędzia, które wspierają tworzenie "jednostek testowych" dla każdego elementu w programie. Niektóre metodologie (np. Extreme Programming) wymagają, by kod testujący powstawał równocześnie (a najlepiej - przed) implementacją właściwej funkcji. Wiele narzędzi wspiera tworzenie testów (JUnit, xUnit itp.), jednak w tym przypadku tester musi umieć czytać i analizować kod. Narzędzia ułatwiają w zasadzie generowanie szkieletu funkcji testowych i automatyzują uruchamianie testów.

Oprócz testów funkcjonalnych bardzo istotne są analizy wydajności aplikacji. W tym przypadku narzędzia mogą w dużym stopniu wspomóc testera. Pakiety typu LoadRunner czy SiteLoad pozwalają symulować jednoczesną pracę wielu tysięcy użytkowników.