Should We Combine Similar Bugs?

There are two schools of thought when it comes to logging bugs. One is that every product defect should be logged and tracked as its own bug. The other is that multiple similar defects should be combined into a single bug. Which process is more efficient, and is the answer always the same?

Combining Similar Bugs

Combining Similar Bugs

Let’s start with an example. Not long after I learned about accessibility testing, I was asked to take part in a bug bash. Accessibility testing ensures  customers with physical limitations can use the product. It includes verifying the UI works correctly with large fonts, all controls are accessible without a mouse, proper tab order, etc. I decided to try out my new skills and test the UI.

I logged more than 50 defects in the first day of the bash. To my surprise, this did not go over well.

Triage was not happy about evaluating 50 fairly similar bugs. They claimed it would’ve been more efficient to track some of these defects together in a single bug. My fellow testers weren’t too happy either; the bug bash organizer was awarding a prize to the tester who logged the most bugs. It looked to them as if I padded my bug count to win a $10 Panera gift card.

I was told that combining similar defects into a single bug had the following advantages:

  1. The triage process goes quicker. Some of the issues I logged were so similar, there was no need to evaluate them individually.
  2. The bug-fix process goes quicker. If I had combined these defects based on the UI screen where they were found, the developers could have fixed several bugs at once. Instead, they checked-out, modified, and checked-in the same file several times.
  3. The testing process goes quicker. Since developers resolve all the similar defects at once, testers can validate all the fixes at once. This is a tremendous time saver, especially if validating a defect requires deploying a new server or topology.

I was convinced. When we had our next bug bash, I combined my similar defects. I quickly found that although this saved time for the triage team, it added overhead for me.

Every time I logged a bug, not only did I have to check if the same issue was already logged, but I had to check if any similar issue was logged. And what exactly defines similar when it comes to combining bugs? If misaligned text appears on two different UI screens, should they be combined? Do the defects have to be in the same area of the application? Do they need to have the same root cause?

Once these bugs went to triage, more problems were revealed. Several of my combined bugs were closed as “Won’t Fix”. I found that if I combined four defects into one bug, and the triage team determined we shouldn’t fix one of the defects, they rejected the whole bug. It was then my responsibility to create a new bug with just the defects that would be fixed.

There were other issues. Even if the defects were similar, I had no way of knowing the same developer would be assigned to fix all of them. In some cases, the work had to be load-balanced between two developers. These bugs were assigned back to me to split up. I also had to split bugs if triage wanted to assign a different priority or severity to each defect.

Combining bugs didn’t have the expected benefits for the developer, either. When several defects were tracked in the same bug, they all had to be resolved and checked-in together. Developers were no longer able to fix one defect immediately, and save the rest for later.

This leads us back to our original question. Is it better to track multiple similar defects together, or is it better to log them separately? Some defects lend themselves to being combined, such as when the same UI screen has three hardcoded strings. Others don’t, such as when two sets of repro steps with different call stacks both result in a “can’t connect to web service” error.

I suggest you first get your team on the same page regarding the criteria for combining bugs. I’ve found, however, that in almost all cases, it’s better to log defects individually.  The only time it’s more efficient to combine defects is when you know all the following are true. (Here’s a tip: you’ll never know if all the following are true.)

  1. Triage will assign the same status (accept, reject, postpone, etc.) to all the defects.
  2. Triage will assign the same priority and severity to all the defects.
  3. The same developer will be assigned to fix all the defects.
  4. The developer will be making all the fixes at the same time.
  5. The same tester will be assigned to validate all the fixes.

Some bug-tracking systems allow related bugs to be “linked” together, which is a great compromise. Now when I log bugs, I almost always follow the “one defect per bug” rule. But if I log similar bugs, I use this feature to link them together.  The triage team might not be crazy about it, but it saves me and the company time. As a side benefit, I also have a wallet full of Panera gift cards.

%d bloggers like this: