Testowanie oprogramowania – proces związany z wytwarzaniem oprogramowania. Jest to część procesów zarządzania 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. metody zwinne) 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^[1].

Glenford J. Myers(inne języki) zaproponował odróżnienie debugowania od testowania w publikacji z 1979 r., chociaż jego uwaga była poświęcona testom na złamanie – „A successful test case is one that detects an as-yet undiscovered error”, czyli „udany przypadek testowy to taki, który odkrywa dotąd nieznany błąd”. Zilustrował chęć społeczności inżynierów oprogramowania do oddzielenia podstawowych działań rozwojowych, takich jak debugowanie, od weryfikacji^[2].

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ń. Spora część defektów jest spowodowana niejednoznacznymi wymaganiami i skutkuje nieprawidłowym wskazaniem obecności defektu tak jak w tablicy pomyłek. W sytuacji gdy wymagania są niejasne to ciężko jest określić poprawne zachowanie systemu. W skrajnych przypadkach taki defekt może być celowo nienaprawiany lub odłożony do naprawy w kolejnej iteracji^[3].

Testy można 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 regresji – testy oprogramowania po wykonaniu zmian, niekoniecznie w kodzie (przykładowo aktualizacji wersji systemu operacyjnego)

Testy oprogramowania można podzielić też na dwie główne kategorie:

• testy ręczne – wykonywane przez testerów, którzy ręcznie przeprowadzają testy, interagując z oprogramowaniem, sprawdzając funkcjonalności i szukając błędów
• testy automatyczne – polegają na wykorzystaniu narzędzia do automatyzacji procesu testowania. Skrypty testowe są tworzone, a następnie uruchamiane automatycznie, co pozwala na szybsze i powtarzalne testowanie. Testy automatyczne są efektywne w przypadku częstych zmian w kodzie i pozwalają na wczesne wykrywanie błędów. ^[4]

Do weryfikacji jakości kodu coraz częściej wykorzystywane są narzędzia oparte na sztucznej inteligencji (AI). Te technologie umożliwiają analizę kodu źródłowego w sposób bardziej precyzyjny i skuteczny niż tradycyjne metody. Narzędzia AI są w stanie wykrywać potencjalne błędy, niezgodności ze standardami programowania oraz sugerować optymalizacje na podstawie analizy kontekstu i złożoności kodu.^{[5] [6]}

Testy dzieli się na pięć poziomów^[7]:

• testy jednostkowe
• testy integracyjne komponentów
• testy systemowe
• testy integracyjne z systemami
• testy akceptacyjne, w których możemy wyróżnić również specyficzne dla oprogramowania komercyjnego testy alfa i testy beta

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:

• IEEE 829- 2008 Standard for Software and System Test Documentation
• ISO / IEC / IEEE 29119 Software Testing Standard
• IEEE 730-2014 Standard for Software Quality Assurance Processes
• ISO/IEC 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models

• Testowanie eksploracyjne
• Tester gier
• Beta-tester

• Słownik pojęć związanych z testowaniem