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—>

Metrics your Agile team should & should not be tracking!

Agile teams are constantly running toward goals, requiring constant planning, monitoring, and re-planning. Metrics can help support these efforts by providing useful information about the health and progress of the project.

There are a few common metrics we use in agile teams: sprint burndown charts, release burnup charts, team velocity. They’re common because they communicate practical information, but they’re not the only metrics we can employ.

In my recent articles for TestRail blog, I described 3 Uncommon metrics you can easily create that will be very useful for your agile team. I also wrote about 3 Metrics that are not useful and you must stop using now!

Here are the posts–>

Three Uncommon Metrics Your Agile Team Should Be Tracking

Here I described 3 most useful metrics –

Defect Health

Defect Health Chart

Test Progress

Metric for weekly test progress

Build Failures

Sprint-wise metric for No of Build Failures

Click here to read the complete article —>

Three Metrics Your Agile Team Should Stop Using

Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.

In this post I have described three metrics that can impede your agile team instead of motivating you.

  • Defect Counts
  • Hours
  • Lines of Code or Defect Fixes per Developer

Click here to read the complete article–>

Please share your experiences with metrics and how they helped or impeded your progress!

Cheers

Nishi

Components of a Defect Management Software

 Since software developers and testers work together in the Agile and DevOps environments, it gets challenging to cope up with the increasing competition. Development teams work in collaboration with various stakeholders to make the most of the testing efforts. Defects in software applications are a norm, the sooner you realize that better it is. It is impossible to have a 100% defect/error-free software application, but experts work to make the most of their efforts. The current need for faster delivery and quality products calls for robust software testing solutions that can meet customer expectations.

A defect management system is a defect repository where all the defects appearing in a system are identified, recorded and assigned for rectification. This system includes defect management software and defect management tools to achieve projects efficiently. 

How Does Defect Management Work?

A defect management system works in a systematic manner, and records all the defects in the system without duplicating defects, and maintaining a log for future use too. There are different steps involved in the defect management that are explained below–

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 »