Odpowiedź.

Historia pytania:

Problem wystarczalności testów pojawił się, gdy projekty stały się duże, a czasu było mało. Stało się konieczne zrozumienie, kiedy należy zakończyć testowanie, aby efektywnie wykorzystać zasoby. Tester musi wyjaśnić biznesowi, że przetestowano „wystarczająco”, a ryzyko jest minimalne.

Problem:

Ręczne testowanie nie może być absolutnie pełne — zawsze istnieją ograniczenia czasowe i zasobowe. Niewystarczające pokrycie prowadzi do przeoczonych defektów, a nadmiarowe powoduje przekroczenie budżetu i opóźnienia.

Rozwiązanie:

Używać metryk pokrycia: procent zaliczonych wymagań, pokrycie kodu (jeśli jest dostęp), stosunek unikalnych scenariuszy/modułów.
Wprowadzać praktyki macierzy śladowości dla zgodności test-case'ów z wymaganiami.
Przeprowadzać wspólne przeglądy test-case'ów i defektów z zespołem.

Kluczowe cechy:

Harmonizacja między wymaganiami, test-case'ami a modułami funkcjonalnymi.
Ocena ryzyk w celu ustalenia priorytetów.
Możliwość jednoznacznego uzasadnienia, dlaczego testy zostały zakończone.

Pytania podchwytliwe.

Czy można opierać się tylko na pokryciu test-case'ami bez uwzględnienia ryzyk?

Nie. Należy uwzględniać priorytety funkcjonalności: które obszary są najbardziej krytyczne dla biznesu.

Czy zawsze liczba test-case'ów mówi o jakości pokrycia?

Nie. Dużo nieuzasadnionych lub powtarzających się test-case'ów to nie oznaka wysokiego pokrycia.

Czy należy uwzględniać w metryce pokrycia testy eksploracyjne?

Tak, koniecznie. Testowanie eksploracyjne wykrywa nieoczekiwane defekty, które nie zostały znalezione przez formalne test-case'y i powinno być częścią ogólnego obrazu pokrycia.

Typowe błędy i antywzorce

Skupienie się tylko na formalnych wskaźnikach, ignorując ważne obszary ryzyka.
Ukrywanie niedociągnięć pokrycia (niewzięte pod uwagę wymagania, nieopracowane scenariusze).
Przekroczenie terminu z powodu dążenia do „pokrycia wszystkiego”.

Przykład z życia

Negatywny przypadek

Tester uważa pokrycie tylko na podstawie liczby test-case'ów bez uwzględnienia strefy wpływu błędów lub scenariuszy użytkowników.

Plusy:

Łatwo przedstawić ładne raporty.

Minusy:

Krytyczne błędy mogą pozostawać poza polem widzenia.

Pozytywny przypadek

Tester wraz z analitykiem precyzuje ryzyka, dostosowuje pokrycie i koncentruje wysiłki na najważniejszych komponentach.