Quality issues such as defect clustering are common when teams are building out a more complex product using defect tracking tools. In this article, we’ll explore what role do defect clusters play in bringing down the quality.
Defect Clustering
It’s not often that bugs are distributed equally throughout an application. In simple words, defect clustering occurs when the majority of the quality issues are caused by a small number of features in an application.
There can be numerous causes of defect clustering, from legacy code prone to breaking to newer features that are undergoing frequent changes, to a particularly fickle 3rd-party integration. Whatever the reason, you must be able to identify defect-prone areas of your product with the help of defect tracking tools.
Key Indicators of Defect Clustering
A few clear signs indicate that you might be facing a defect clustering problem:
- Issues appear regularly despite having a significant number of test cases
- Bugs seem to crop up in one or two “problem features” most frequently
Minimizing Defect Clustering
I may be stating the obvious but in case you don’t know, you can get the greatest returns by making improvements that focus on a specific application, codebase or product feature that house the majority of issues. There can be numerous causes of defect clustering, from legacy code prone to breaking to newer features that are undergoing frequent changes, to a particularly fickle 3rd-party integration.
You don’t have to abandon everything else in the interim. All you need is to relocate a few extra resources to make a difference in the targeted technology.
For instance, if most of the customer complaints are regarding a particular aspect of the product then a short improvement initiative would work well if it’s solely focused on improving quality around that aspect. For that, you might have to borrow some developers or product managers from other projects and re-assign them for a time-period required to build up test coverage or automation around that area. And don’t forget to equip them with relevant defect tracking tools that can prove to be a valuable weapon in your fight against defect clustering.
Data-Driven Approach to QA Coverage
Best decisions are made that are based on facts rather than feelings. Quentin Thomas, Bleacher Report’s Senior Automation Engineer, while sharing his experience, told that he managed to take a trove of defect data from his organization to prove that a lightly-maintained old codebase was the source of the majority of issues. Instead of suggesting the organization to focus extra resources into coverage for that code-base, the data indicated it may be needed to be abandoned altogether. I may be stating the obvious but in case you don’t know, you can get the greatest returns by making improvements that focus on a specific application, codebase or product feature that house the majority of issues.
He said that the data served as sufficient evidence to make his point that instead of trying to spend all the time to test and analyze, it’s better to phase it out since it was causing a lot of issues.
“Sometimes getting rid of a service no one is maintaining is going to do a better job of improving quality than anything QA can do.”
Author Bio:
Muhammad Akhtar completed his B.Sc. degree from the IUB University in 2013. He is co-founder of Read Dive. His career in SEO and Digital Marketing kicked off in 2014 when he joined CureMD. Since then, his professional journey has taken him to QualiTest and IQVIS. Currently, he enhances the digital marketing strategies of Kualitatem and its product Kualitee. His portfolio adorns various certifications including Google Analytics, Inbound Marketing, SEO and Social Media Marketing.
About The Author
