Korzyści z automatyzacji nie zawężają się jedynie do przyspieszenia wykonywania testów. Pewne rodzaje testów, np. testy na przeciążenie lub wydajności, są bez zastosowania specjalistycznych narzędzi w praktyce niewykonalne lub bardzo kosztowne.

Narzędzia testujące umożliwiają np. rejestrację krótkotrwałych zjawisk niedostrzegalnych ludzkim okiem, dokładny pomiar czasu wykonywania określonych funkcji w systemie oraz tak ważną synchronizację stymulacji systemu testującego z reakcjami systemu testowanego, co pozwala wykryć ewentualne tzw. błędy czasu rzeczywistego.

Warto też zaznaczyć, że uzyskanie jak największych zysków - w wymiarze finansowym czy czasowym - nie musi być bezpośrednim wynikiem automatyzacji procesu wykonywania testów. W niektórych przypadkach bardziej opłacalne może się okazać np. zastosowanie narzędzi do... automatycznego śledzenia związków przypadków testowych ze specyfikacją wymagań lub do śledzenia zgłoszeń błędów.

Uwaga na miny

Podstawowym zagrożeniem wdrożeń systemów automatyzujących testy są sygnalizowane już nierealistyczne oczekiwania. Wielki udział mają w tym sprzedawcy. "Czarując" klientów funkcjami typu "nagraj-odtwórz" (capture-replay albo capture-playback), zapominają dodać, że ich zastosowanie jest bardzo ograniczone i nie zwalnia całkowicie z "ręcznego" definiowania przypadków testowych i budowy skryptów.

Często popełnianym błędem jest przekonanie, że automatyzacja wykonywania testów oznacza automatycznie skrócenie czasu potrzebnego na testowanie i w efekcie skrócenie czasu trwania projektu jako całości. Trzeba pamiętać, że oprócz automatycznego wykonywania testów, automatyzacja testowania obejmuje m.in. instalowanie i odpowiednie dostrojenie narzędzi, szkolenia posługujących się nimi testerów oraz, co najistotniejsze, wymyślenie i konstruowanie "roboczych" programów i skryptów testujących. Im większa zmienność testowanego systemu podczas projektu, tym więcej czasu potrzeba na wprowadzanie odpowiednich zmian do wszystkich programów i narzędzi testujących.

W ten sposób zostały zidentyfikowane dwie pierwsze pułapki: pułapka pierwsza - niedocenianie kosztów wdrożenia automatyzacji, pułapka druga - pominięcie w kalkulacjach czasu i środków potrzebnych na utrzymanie systemu do automatycznych testów, spowodowane niestabilnością przedmiotu testowania. Oczywiście na tym nie koniec. Pułapka trzecia pojawia się tam, gdzie zamiar automatyzacji testów został podjęty po zdefiniowaniu architektury i założeń konstrukcyjnych systemu. Nieuwzględnienie w projekcie wymagań narzędzi testujących może powodować różne problemy, np. brak portów do komunikacji między narzędziami testującymi a testowanym systemem, brak dostatecznej ilości pamięci czy nieobsługiwanie określonych protokołów komunikacyjnych bądź formatów danych. Przykłady tego rodzaju można by mnożyć.

Wybuchowa architektura

Sprawą niebagatelną, mogącą łatwo przekształcić się w pułapkę czwartą, są kwalifikacje zespołu testującego. Podczas wdrożeń systemów do automatyzacji testów często zapomina się, że pisanie skryptów/programów testujących wymaga umiejętności programowania i metodyki - nie gorszych, a w niektórych przypadkach nawet lepszych niż w procesie produkcji oprogramowania właściwego. Z dużą dozą prawdopodobieństwa można założyć, że zatrudnienie przy wdrożeniu systemów automatyzujących testy osób wykonujących dotychczas testy akceptacyjne - będących w istocie specjalistami w dziedzinie funkcjonalności systemu z punktu widzenia użytkownika końcowego, a nie wewnętrznej konstrukcji systemu - skończy się fiaskiem całego przedsięwzięcia.

Wynikiem niedostatecznych umiejętności osób wdrażających system automatyzacji testów jest z reguły zła architektura, będąca piątą pułapką na drodze do automatyzacji testów. Czym jest zła architektura? Przykładowo, jeżeli wiele skryptów testowych posługuje się kliknięciem na przycisk OK, dobrym rozwiązaniem jest stworzenie małego skryptu klikającego, który będzie mógł wywoływać inne programy testujące. Rozwiązaniem złym jest zaś kodowanie tej czynności osobno w każdym skrypcie. Przykład drugi: jeżeli działanie programu testującego polega na tym, by wielokrotnie wprowadzać rozmaite dane osobowe do bazy danych za pośrednictwem tego samego okna dialogowego, to rozwiązanie dobre polega na tym, aby kod - w tej sytuacji w formie prostej pętli - był jeden, a same dane (a także i dane, i komunikaty będące wynikami prób ich wprowadzenia) były przechowywane w osobnym pliku, skąd program by je sobie kolejno odczytywał. Rozwiązanie złe może polegać np. na napisaniu kilkudziesięciu metrów bieżących kodu, w którym każda iteracja będzie identyczna z wyjątkiem danych wejściowych.