Ponieważ jednym z celów testowania jest znajdowanie usterek, rozbieżności pomiędzy oczekiwanymi i rzeczywistymi wynikami muszą być zapisywane jako incydenty. Incydenty powinny być analizowane i może się okazać, że stanowią defekty. Odpowiednie czynności, mówiące jak należy postępować z incydentami i defektami, powinny zostać zdefiniowane. Incydenty i defekty powinny być śledzone od momentu wykrycia i klasyfikacji do naprawy i potwierdzenia rozwiązania. Żeby być w stanie zarządzać wszystkimi incydentami aż do ich zamknięcia, organizacja powinna wprowadzić proces zarządzania incydentami oraz reguły klasyfikacji.

Incydenty można zgłaszać podczas programowania, przeglądów, testowania lub użytkowania produktu softwarowego. Mogą być zgłoszone dla problemów w kodzie lub działającym systemie, a także dla dokumentów dowolnego typu, czyli wymagań, dokumentów deweloperskich, dokumentów testowych lub informacji dla użytkownika takich jak pomoc lub instrukcja instalacji.

Raporty incydentów istnieją w celu:

• dostarczenia programistom i innym stronom informacji na temat problemów, aby umożliwić identyfikację, wyodrębnienie i naprawę, jeżeli okaże się to konieczne
• dostarczenia liderom testów środków do śledzenia jakości testowanego systemu oraz postępu testów
• dostarczenia pomysłów na doskonalenie procesu testowania

Raport incydentów może zawierać następujące szczegóły:

• datę zgłoszenia, zgłaszającą organizację oraz autora
• wyniki oczekiwane oraz rzeczywiste
• wskazanie na element testowy (element konfiguracji) oraz na środowisko
• proces cyklu życia oprogramowania lub systemu w którym incydent został zaobserwowany
• opis incydentu, w celu umożliwienia odtworzenia i rozwiązania, włącznie z logami, zrzutami baz danych oraz zrzutami ekranu
• obszar lub stopień wpływu na interesy interesariuszy
• stopień wpływu na system
• pilność, priorytet naprawy
• status incydentu (np. otwarty, odłożony, duplikat, oczekujący na naprawę, naprawiony i oczekujący na retest, zamknięty)
• podsumowania, rekomendacje oraz zgody
• zagadnienia globalne, takie jak inne obszary, na które mogą mieć wpływ zmiany związane z incydentem
• historia zmian, np. ciąg czynności podjętych przez członków zespołu w celu wyizolowania incydentu, jego naprawy oraz potwierdzenia tej naprawy
• referencje, włączając w to identyfikator specyfikacji przypadku testowego, który wykrył problem

Struktura raportu incydentu jest również przedstawiona w dokumencie „Standard for Software Test Documentation” (IEEE STD 829-1998).