"Kumulowanie się błędów blisko siebie" jest faktem wymienianym wśród siedmiu klasycznych zasad teorii testowania - i jako takie może być tematem pytań nawet na podstawowych egzaminach certyfikacyjnych. 

Należałoby uściślić najpierw używane w tym zapisie słownictwo. Gdy mówimy o faktycznych niedoróbkach w samym kodzie, które występują częściej w danych modułach testowanego systemu niż w innych, to należałoby zgodnie z definicjami wymaganymi przez ISTQB  mówić nie tyle o "błędach", co o "defektach" - natomiast brak konsekwencji co do tych dwóch pojęć jest tak powszechny w literaturze tematu, że wiele osób uznaje, że słowo "błąd" w rozumieniu "defekt" weszło do uzusu językowego. 

Zjawisko opisywane tutaj jest stwierdzane empirycznie od dawna i polega na tym, że rozkład odnajdowanych w systemie przy założonym ujednoliconym testowaniu jest nierównomierny. W pewnych modułach kodu defektów jest więcej niż w innych. Charakterystyczne przy tym jest to, że statystycznie najwięcej defektów wyłapuje się w modułach najmniejszych i największych, podczas, gdy moduły o średniej wielkości/złożoności okazują się najmniej "nasycone" defektami. 

Oszacowanie takie, oparte na przyjętej mierze wolumenowej, warto zmodyfikować w oparciu o dane historyczne, które pomagają uwzględnić konkretne cechy i tendencje w budowanym systemie. Docelowo prowadzone statystyki powinny wykazać, jakiej wielkości moduły realizujące pojedyncze funkcjonalności obciążone są jakim szacunkowym ryzykiem wystąpienia w nich defektów. 

Opisana tu prawidłowość będzie więc przydatna przede wszystkim przy szacowaniu ryzyka, ustalaniu, które rejony systemu należy potraktować priorytetowo w projekcie testowym, oraz jak przewidzieć alokację zasobów do wykonania tych zadań.