Fighting Defect Clusters in Software Testing

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.

In my article for Gurock blog, I discussed some ways to fight Defect Clusters in Software Testing:

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, like utilizing

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.

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 Clusters

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. Continue Reading—>

Four Goals of Testing Beyond Finding Defects

Are you testing with the sole purpose of finding defects? What if you don’t find any? Your testing should deliver more value than just finding bugs. In my article published at https://blog.gurock.com/, I examined the true goals of testing and how we can aim at achieving all four of them for the quality benefits of our software.

Gaining knowledge about defects 

While there is more to testing than pinpointing bugs, finding defects and problems is the first instinctive goal. Looking for places where the functionality breaks or does not work as expected is key. 

Testers can adopt a number of approaches, test techniques and strategies to find these problems before users do. This helps the team keep updated on the status of product quality, fix the problems, and improve the software for the users.

Proving functionality

If you have been testing diligently and going through a bunch of test cases and various scenarios but haven’t yet found a defect, it doesn’t mean it was all for nothing! If a test doesn’t fail, that means it passed, and that is useful information, too.

Another major goal of testing is to prove that the functionality works fine, and it is that proof that helps us make decisions about its future. Without this proof, we would never have a clear picture of the software’s quality, its intended functionality or whether it’s fit for use. Many teams would also get into problems with regulations, audits, and compliance without this proof of functionality.

Generating information

Testing also generates a lot more information than just passing or failing tests. Testers generally have loads of questions occur to them while testing. They may be about the need, implementation or design of the features, their related integrations with existing features, or actual usage scenarios. The answers to these questions are paramount in making the feature assimilate well within the software. 

Read More »

What can you learn from the defects you found?

The bugs we find during testing can tell us a lot about the application, the state of its quality and its release-readiness. Bugs can also provide insights into our development processes and practices — and lapses therein.

How can we study bugs to improve the overall state of our project? In my article published @Gurock TestRail blog, I have described three things to learn from the bugs you find. https://blog.gurock.com/three-learn-bugs/

 The location of defect clusters

Defect clustering is one of the seven principles of software testing, and keeping an eye out for these clusters is the responsibility of a good tester.

As we log defects into a tracking tool or portal, teams generally follow the practice of measuring relevant modules, components or functional areas against each defect. When tracked over time, this information can be real gold! It helps us track which areas of the application are having more bugs.

Read More »