Tworzenie testów, które może nastąpić po zakończeniu ich projektowania, polega na utworzeniu (lub nabyciu w inny sposób) procedur i przypadków testujących weryfikujących spełnienie wymagań. Preferowane są techniki wydajne, lecz przy tym łatwo pielęgnowalne i nadające się do wielokrotnego użytku. Główne kroki tej fazy to:

- inicjalizacja/konfiguracja środowiska tworzenia testów

- zapisanie prototypowych procedur testujących

- zapisanie procedur i przypadków testujących

- testowanie i usuwanie błędów z procedur testujących (testowanie testów!)

- modyfikowanie procedur testujących (opcjonalne)

- przygotowanie zewnętrznych zbiorów danych

- ponowne testowanie i usuwanie błędów z procedur testujących.

Wykonywanie testów, czyli to, co potocznie rozumiemy przez testowanie, znajduje się w metodyce SQA jako jej czwarta faza. Polega ona na uruchamianiu utworzonych procedur testujących i zastosowaniu ich do (aktualnie testowanej wersji) systemu. Wykonywanie testów ma z założenia charakter zautomatyzowany, co jest zresztą praktyczną koniecznością w sytuacji, gdy poszczególne procedury testujące uruchamiane są nawet 50-100 razy podczas jednego cyklu testowania, zaś liczba tych procedur, wobec złożoności testowanych aplikacji klient/serwer, jest z reguły bardzo duża. Podstawowe kroki wyróżnione w tej fazie są następujące:

- inicjalizacja/konfiguracja środowiska testowania

- przygotowanie do wykonania procedur testujących

- uruchomienie procedur inicjalizujących

- wykonanie testów

- odtworzenie stanu systemu po awaryjnie zakończonych testach

- weryfikacja oczekiwanych rezultatów

- wyjaśnianie nieoczekiwanych rezultatów

- zapisanie zaobserwowanych błędów.

Ocena testów w naturalny sposób następuje po ich wykonaniu jako nieodzowna logiczna konsekwencja. Ma ona na celu określenie czy kryteria testowania (określone w fazie planowania) zostały spełnione. Po przeglądzie zapisów z fazy wykonywania specyfikuje się rodzaje raportów i wykresów potrzebne dla ustalenia jakości testowanego oprogramowania i zakończenia testów. W fazie tej uzyskuje się odpowiedź na pytanie czy konieczne jest dalsze testowanie systemu, czy też może on być już przekazany do użytku. Dokładniej, metodyka SQA Process przewiduje cztery kroki oceny testów:

- przegląd zapisów z wykonywania testów

- ocenę spełnienia wymagań testowych

- ocenę zaobserwowanych błędów

- określenie, czy zostały spełnione kryteria zakończenia testowania.

Śledzenie błędów to raczej proces niż faza, który w metodyce SQA służy zapewnieniu każdemu członkowi zespołu projektowego dostęp do informacji na temat testowania i wykrywanych błędów. Realizuje się to przez repozytorium, w którym zapisywane są jako potencjalne błędy, symptomy zaobserwowane w czasie testowania (a także problemy zgłoszone przez użytkowników, jeśli system został już przekazany do użytku). W miarę, jak są one wyjaśniane i ewentualne błędy usunięte, etykietuje się je w repozytorium jako przypadki rozwiązane. Proces ten jest integralną częścią nie tylko cyklu testowania, lecz także całego cyklu życia systemu i powinien być kontynuowany również w odniesieniu do systemów przekazanych do użytku w celu ułatwienia przygotowywania przyszłych ulepszonych wersji. Kroki, jakie wykonuje się w tym procesie, to:

- zapisywanie symptomów błędów do repozytorium

- wyjaśnianie poszczególnych przypadków

- usuwanie błędów

- ocena efektów

- uznawanie symptomów błędów za wyjaśnione

- generowanie raportów o błędach.

Odnaleźć brakujące ogniwo

Przedstawiony w tym artykule opis metodyki testowania oferowanej przez firmę SQA Inc. jest oczywiście bardzo pobieżny i ogólny, jest więc naturalne, że pozostawia niedosyt. Naszym celem w tej pierwszej publikacji na ten temat nie było wchodzenie w szczegóły, lecz raczej skierowanie do Czytelników zajmujących się systemami klient/serwer sygnału o tym, że istnieje coś, o czym być może jeszcze nie wiedzą, a co może być im bardzo pomocne i czym prawdopodobnie zechcą się bliżej zainteresować.

Nawet jeśli nie wszystkie z poddawanych w tym tekście pod rozwagę argumentów trafią wszystkim do przekonania, to dla praktyków najlepszym argumentem będą z pewnością ich dotychczasowe doświadczenia z testowaniem. Jeśli przezwyciężą nieufność do nowości (tak jak zrobili to już przed nimi nabywcy kilkanastu tysięcy licencji pakietu SQA TeamTest na całym świecie), być może odkryją brakujące ogniwo w swoich środowiskach tworzenia oprogramowania, ogniwo, którym jest systematyczna metodyka zautomatyzowanego testowania. Dzięki niej łatwiej osiągalny się staje powtarzalny i przewidywalny proces testowania, zrozumiałe strategie testowania, właściwe wykorzystanie personelu do testowania oraz czytelne określanie i komunikowanie wymagań do testowania dla każdego projektu, zaś ryzyko dostarczenia odbiorcy produktu obarczonego błędami ograniczającymi jego użyteczność jest wyraźnie zredukowane.