W skrajnych przypadkach taki defekt może być celowo nienaprawiany lub odłożony do naprawy w kolejnej iteracji.
Podział testów thumb|TestingCup – Mistrzostwa Polski w testowaniu oprogramowania, Katowice, MCK, maj 2016 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 () 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.