Wymień kryteria wyboru dokumentacji testowej.

Grupa docelowa: Zrozumienie, kto będzie korzystał z dokumentacji (programiści, inni testerzy, menedżerowie), określa poziom szczegółowości i styl prezentacji.
Złożoność projektu/funkcjonalności: Dla krytycznych lub złożonych części systemu wymagana jest głębsza i bardziej szczegółowa dokumentacja (np. przypadki testowe z warunkami wstępnymi, krokami, oczekiwanym wynikiem). Dla prostych funkcji wystarczą listy kontrolne.
Ryzyko: Wysokie ryzyko wymaga sformalizowanych i szczegółowych scenariuszy testowych, aby zapewnić pokrycie.
Wymagania dotyczące śledzenia: Konieczność powiązania dokumentacji testowej z wymaganiami (macierz śledzenia) wpływa na strukturę i zawartość dokumentów.
Cykl życia rozwoju oprogramowania (SDLC): Na wczesnych etapach można używać wysokopoziomowych planów testów i strategii, na późniejszych etapach – szczegółowych przypadków testowych.
Używane narzędzia: Systemy zarządzania testami (TMS) lub narzędzia do śledzenia błędów mogą wpływać na format i strukturę dokumentacji testowej.
Czas i zasoby: Objętość i szczegółowość dokumentacji powinny być proporcjonalne do dostępnego czasu i zasobów zespołu.
Standardy korporacyjne: Obecność ustalonych szablonów lub standardów w firmie określa format i zawartość dokumentacji.
Utrzymanie: Dokumentacja powinna być łatwo utrzymywana i aktualizowana w miarę zmian funkcjonalności.
Jasność i jednoznaczność: Dokumentacja powinna być zrozumiała, bez dwuznaczności, aby każdy członek zespołu mógł z niej korzystać.