Wstęp

Testowanie oprogramowania – proces związany z wytwarzaniem oprogramowania. Jest to jeden z procesów zapewnienia jakości oprogramowania. Testowanie ma na celu weryfikację oraz walidację oprogramowania. Weryfikacja oprogramowania pozwala skontrolować, czy wytwarzane oprogramowanie jest zgodne ze specyfikacją. Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika. Testowanie oprogramowania może być wdrożone w dowolnym momencie wytwarzania oprogramowania (w zależności od stosowanej metody). W podejściu kaskadowym zgodnym z modelem V wysiłek zespołu testerskiego zaczyna się wraz z definicją wymagań i jest kontynuowany po zaimplementowaniu zdefiniowanych wymagań. Nowsze metody wytwarzania oprogramowania (np. Agile) rozkładają wysiłek testerski równomiernie na poszczególne iteracje i skupiają się na testach jednostkowych oraz automatyzacji weryfikacji wykonywanych przez członków zespołu.

Testowanie nie jest w stanie wykryć wszystkich defektów oprogramowania, jednak może dostarczyć informacji o jego zgodności z wymaganiami klienta, czy też z jego oczekiwaniami. Trzeba pamiętać, że testowanie nie sprawdza oprogramowania pod kątem wszelkich możliwych warunków początkowych, lecz jedynie w wyselekcjonowanych warunkach. Testowanie może we wczesnych fazach projektu wykryć defekty nie tylko oprogramowania, ale i specyfikacji wymagań czy projektu. Wczesne wykrycie defektu jest ważne z ekonomicznego punktu widzenia, ponieważ gwarantuje niższe koszty jego naprawy. Defekty oprogramowania nie wynikają jedynie z błędów kodowania. Duża część defektów jest wynikiem błędów popełnionych podczas definicji wymagań. Testowanie oprogramowania sprowadza się również do analizy statycznej i testowania wymagań.

Podział testów

Testy możemy podzielić na kilka sposobów

• ze względu na weryfikowane obiekty (przykładowo testy klas, komponentów, podsystemów, systemu lub zintegrowanych systemów)
• na białoskrzynkowe (strukturalne), weryfikujące kod źródłowy oraz czarnoskrzynkowe testujące warstwę interfejsu
• bazujące na wymaganiach (testy weryfikujące zgodność implementacji z wymaganiami, np. testy funkcjonalne, testy graficznego interfejsu użytkownika), testy niefunkcjonalne – por. klasyfikacja wymagań (i testów) FURPS+ zdefiniowana w ramach Rational Unified Process (RUP) czy testy weryfikacji (testy sprawdzające zgodność implementacji z założeniami np. programisty)
• ze względu na metodę weryfikacji z wyróżnieniem testów statycznych, bez uruchomienia aplikacji i testów dynamicznych wymagającej pracę na uruchomionym oprogramowaniu

Częstym błędem jest stawianie znaku równości między testami funkcjonalnymi, a testami czarnej skrzynki. Testy funkcjonalne mogą wymagać umiejętności czytania kodu źródłowego, czego nie wymaga się przy testach interfejsów zewnętrznych.

Dodatkowo można wyróżnić testy wykonane w określonym celu:

• retesty – testy poprawek defektów
• testy regresywne – testy oprogramowania po wykonaniu zmian, niekoniecznie w kodzie (przykładowo aktualizacji wersji systemu operacyjnego)

Standardy w testowaniu

W testowaniu zdefiniowano kilka standardów, ale żaden z nich nie odgrywa poważniejszej roli w formalizowaniu testowania, ani nie został powszechnie przyjęty za obowiązujący.

Przykładowe standardy w testowaniu: