This is a guest post by Nishi Grover Garg.
Defects tend to cluster in some areas of the software under test. It may happen due to higher complexity, algorithms, or a higher number of integrations in a few constrained segments of the software.
These defect clusters can be tricky, both to find and to deal with. Testers need to be on constant alert for ways to isolate defect clusters and devise ways to overcome them, fight those defects and move on to new clusters.
Locating Defect Clusters
Most defects tend to cluster in certain areas of your software. It is one of the seven testing principles. Many testers intuitively know of these defect-prone areas, but we can still strive to be on the lookout for clusters of defects in a number of ways.
Metrics
Using metrics like defect density charts or module-wise defect counts, we can examine the history of defects that have been found and look for areas, modules, or features with higher defect density. This is where we should begin our search for defect clusters. Spending more time testing these areas may lead us to more defects or more complex use cases to try out.
For example, the chart below shows that Module 4 has the most defects, so it would be smart to continue concentrating on that module in the future.
You can also track the number of defects per line of code, or plot defect density measures on a chart or graph.
History
Use the defect management system and the history of the software to go through older defects, and try to replicate them in the system. You will get to know the system’s history, where it broke and how it works now. You may learn a lot about the software and find many new areas to test.
Experience
A tester’s intuition, experience and history with the product is by far the best way to find defect clusters. Lessons learned by experienced teammates should be shared with new coworkers so that the knowledge can be passed on, utilized and improved upon by exercising these defect-prone areas with new perspectives.
Fighting Defect Clustering
Defect clustering follows the Pareto rule that 80% of the defects are caused by 20% of the modules in the software. It’s imperative for a tester to know which 20% of modules have the most defects so that the maximum amount of effort can be spent there. That way, even if you don’t have a lot of time to test, hopefully, you can still find the majority of defects.
Once you know the defect cluster areas, testers can focus on containing the defects in their product in a number of ways.
Devise better ways to test that area
By knowing which features or modules contain most defects, testers can spend more effort in finding better ways to test it. They can include more unit tests and integration tests for that module. Testers can also write more in-depth test scenarios with use cases from the customers on how the feature is best used in production.
Focusing on test data and creating more exhaustive combinatorial tests for variables can also lead to finding more computational or algorithmic defects sooner.
Keep more time in the test plan to test that area
Since each feature is not equally important, complex, or “dirty,” they usually do not all require equal effort or time to test. By locating defect clusters, testers can plan to allocate more test effort and time to defect-dense areas or modules that are prone to defects.
This transparency also makes the testers’ job easier when estimating tasks and reporting actual times spent per user story. Testers working on a defect-dense area may be working twice the amount of time on that one user story that it takes another tester to work on multiple smaller modules. This knowledge keeps the task distribution fair and open with realistic expectations.
Have more eyes on that area
A defect-dense module should undergo a higher level and number of reviews in order to prevent defects in the future. Peer reviews and buddy tests can be performed in various stages so that we have varied perspectives and feedback on the feature design, implementation, and tests.
A Constant Process
Once a defect cluster is identified and the team begins implementing the above tactics to fight it, the number of defects may then reduce, and over time that particular defect cluster may no longer be a threat. By then, the system may have new complex areas that become the defect magnets!
Testers need to be on a constant lookout for defect clusters. Looking for and fighting defect clusters is a constant process that evolves along with the application.
Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
