"Defects are social creatures" - mawiał nieodżałowany Bogdan Bereza, który tym stwierdzeniem kwitował temat kumulowania się defektów w jednym obszarze i związków między defektami. Aspekt powiązania defektów między sobą można analizować w wielu wymiarach projektowych i wytwórczych. Poniżej prezentujemy trzy.
1. Niepoprawne zachowanie aplikacji ogólnie możemy nazwać defektem. Defekt może mieć wiele konsekwencji dla aplikacji, w której się znajduje, np. może powodować inne problemy. O defekcie, który generuje inne defekty mówimy jeśli eliminacja defektu (źródłowego) powoduje, że również powiązane z nim defekty przestają istnieć. Przykład: niepoprawna walidacja formularza może powodować, że nie uda się go uzupełnić i zakończyć pomimo poprawnych danych. Możemy więc zaraportować defekt niemożności ukończenia akcji na formularzu lub wskazać, że ten problem wynika z konkretnego problemu walidacji danych. Usunięcie defektu walidacji powoduje, że defekt całego formularza (defekt wynikający z defektu) rozwiązuje się automatycznie. Możemy uznać, że jakaś część oprogramowania jest zablokowana przez defekt, co z kolei przekłada się na sytuację, w której defekty nie mogą być wykryte, ponieważ dostęp do nich jest niemożliwy.
2. Analizując oprogramowanie czasami możemy dostrzec silne podobieństwo między niektórymi defektami. Część z tych zależności wynika ze wspólnego źródła problemu i może być konsekwencją złej praktyki techniki programistycznej nazywanej "kopiuj-wklej". Niepoprawny kod jest kopiowany do wielu miejsc (które czasami wydają się zupełnie niepowiązane). Znalezienie wzorca defektu pomaga wyeliminować go we wszystkich miejscach, w których został "wklejony".
3. Poprawki dla defektów mogą powodować nowe defekty. W publikacjach i prezentacjach pokazujących praktykę wytwarzania oprogramowania można przeczytać o metrykach defektów wynikających z poprawek dla innych defektów, np.
- poprawki dla trzech defektów powodują jeden nowy defekt
- poprawki dla 10 defektów powodują jeden nowy defekt krytyczny itd.
Jest to przypadek, gdy modyfikując kod źródłowy w celu wyeliminowania problemu, do oprogramowania wprowadzamy przypadkowo zupełnie inny defekt. Tak długo, jak ilość i krytyczności defektów naprawianych jest większa niż defektów przez poprawki wprowadzanych możemy mówić o polepszającej się jakości oprogramowania.
To nie jedyne związki i relacje defektów. Czasami są one dużo bardziej złożone i wynikają ze specyfiki tworzonego oprogramowania lub użytej technologii.