Defect Clustering

Defect clustering happens. If there is a bug in one part of the software, chances are there are other, related bugs nearby.

As part of the Seven Testing Principles of the ISTQB Foundation Level Syllabus, on the defect clustering testing principle.

“A small number of modules usually contains most of the defects discovered during pre-release testing or is responsible for most of the operational failures. Predicted defect clusters, and the actual observed defect clusters in test or operation, are an important input into a risk analysis used to focus the test effort.” ISTQB Foundation Level Syllabus

The clustering of defects during testing is often related to the quality of the source code and the consequent ease of testing. The easier it is to test a module, the more likely it is that the module will become a cluster site. Therefore, a common strategy for test engineers is to work towards making testing easier and therefore reducing the likelihood of becoming a cluster site.

The easiest way to do this is by improving the quality of the source code, which may be the responsibility of the development team. However, the test team can also improve the ease of testing by automating as much of the testing as possible with the use of tools, or by reducing the effort required to perform the testing.

Predictive analysis is possible through the use of artificial intelligence algorithms that examine the relationship between variables to generate likely scenarios for testing. These algorithms can also determine a likely cause for each cluster, which is useful for determining the best way to address the cause of the defect cluster. For example, if most of the defects for a specific module were determined to be due to a lack of unit testing, then the most efficient way to address this is to write more unit tests.

In order to predict defect clusters, it is necessary to understand the characteristics of the modules. If a module has a high proportion of defects relative to the average module, it has a high risk. If a module has a high rate of defects, relative to the average module, it has a high risk. If a module has a high number of defects, relative to the average module, it has a high risk. The most efficient way to reduce risk is to re-write the module.