4

The question might not be as simple as it sounds, as we have struggled with this a bit. If there are 5 separate bugs, which can be taken care of with a single fix, then it is wasteful to take this approach. One bug might slip through the cracks, and would take away from a complete picture, or just be hidden for some time (we have several years worth of outstanding bugs, and our bug tracker sucks at searching :( ).

Now, if you file a bug of 100+ parts (such as help tooltips are missing from all 234 dialogs), then it should be treated as a project and be broken down. However, if it is a bug of 3-4 parts, then the developer would attempt to fix all 3 or 4 at once. This is where it gets interesting. What if the coder only fixes 3 or 3.5 out of 4? Should after testing a new bug be filed and old one closed? If yes, then this invites sloppy programming practices, where close enough is good enough. If the bug is to fail, then all of it has to be re-done and re-tested. Now ... what if part 1 is the size of a breadbox in terms of size and risk, part 2 is more like a car, part 3 is like a house, and so on :)

When sizing and prioritizing this bug (I must mention that we use Scrum), the house part was not noticed - who reads anything but a bug title anyway? So, it was deemed a low hanging fruit - low effort, low risk, happy user = high reward. But, we got bitten with one of them recently. What seemed to be logically the same area, was actually code in transitional state, where we are trying to deprecate one method of doing things, or one library for creating widgets with another, new and better. The problem is that we had to release mid-conversion, so we made two very different beasts look alike. Our QA folks did not know that, are not expected to know that, and so in their mind these are all the same issues.

We need to be QA-friendly - not to push back too hard or too often, but also try to give a set of heuristics which would help to decide whether to file one bug or many. I suppose the problem might lie with weak tools, where splitting and merging bugs is hard to do. However, how do you deal with this stuff in general?

P.S. In Scrum - once you committed to fixing something, it probably should be fixed. Break this rule too many times and discipline will degrade.

|improve this question
  • 1
    The body of your question is difficult to read...Is what you want to ask essentially in the title of your question? – Robert Harvey♦ Dec 10 '10 at 23:24
23

5 bugs = 5 bug reports; the fact that they can all be fixed at once is not QA's concern.

in other words, guessing that all 5 bugs stem from the same problem is putting the cart ahead of the horse.

|improve this answer
  • Totally agreed. One more addition I want to do is that, if the developers find that the fix is same. They can mention the same in remaining 4 bug report, and close it. – Manoj R Dec 11 '10 at 6:18
  • Agreed. Where I work, usually the project lead keeps an eye on the bugs reported by QA, and tries to group them and resigns them if necessary. – Jeremy Heiler Dec 11 '10 at 16:55
2

In general, I agree with @Steven Lowe, but on the other hand I don't want to get 10 bug reports, one for each thing that's spelled wrong. I think that the right approach is for QA to use their heads - if they think it's likely that the things are all one big bug, they should be allowed to put them into one bug report. When the developer gets them, and finds out that some of them are one bug, and some are another, the developer can then issue a new bug report on the pieces he doesn't want to fix right now, and update the old bug report to just cover the bits that are fixed.

You'll have to go back and forth a bit with QA on this (because they really don't know for sure when things are related and when they aren't), but I think you'll get the best result (minimum administrative overhead) by having QA use their best judgement, and backfilling in development as needed.

|improve this answer
  • 1
    This can open a door for not really fixing things fully, but only the low hanging fruits. – Job Dec 11 '10 at 20:24
  • @Job: True, but if you try to make a hard-and-fast rule that says everything gets it's own bug, then you end up with a metric ton of administrative overhead dealing with all the bugs, many of which can be combined. It's a tricky balance, and I think the only way to get it really right is to hire QA folk that can use their heads properly. It may also be appropriate that after fixing bug A, and generating bug B (formerly part of A), the same developer should go on to fix bug B as his/her next task. That should help cut down on fixing just the easy bits and leaving the hard bits for someone else. – Michael Kohne Dec 11 '10 at 22:56
  • 1
    @Job: True, but if people want to play games with the system, they will always find a way. OTOH, if a bug turns out to be much more complex than it looked in the beginning, it may be the right decision to implement a partial fix and postpone the rest of the work (because the "rest" is less urgent). – sleske Dec 5 '11 at 15:18
1

I'd go with one bug but if the initial fix covers only part of it then the question becomes should there be a new bug opened for that portion as it could be that what was thought to be fixed at once isn't realistic or something new may be introduced and thus should be a new bug. The key is trying to figure out where is that, "In this case let's make a new bug," line as it shouldn't be that every fix spawns a new bug but in some cases that may make sense to my mind.

My issue with 5 bug reports is that this may mean a lot of administrative overhead that isn't worthwhile as some may want each fix to be done in a separate branch which can be a bit of a waste of time to my mind. Once there is enough experience there should be a good deal of precedence to see where that line lies.

To give a more specific example, imagine a form that has a handful of style issues,e.g. the border doesn't align properly in IE7, in Firefox another part of the form doesn't line up correctly and a few other things that are mostly cosmetic but do cause the form to not meet the specification. Should each issue be logged as a separate bug, which could mean a lot of duplicate work for both QA and development as each bug has to be created, screen shots attached, etc. that doesn't strike me as worthwhile if bundling these together in one bug may be better all around. This has nothing to do with knowing what is or isn't in the code, but rather how finely to slice up things. Some people may like to slice things into itty-bitty pieces but this may be passive-aggressive if the person does it just to piss off a developer. For example, if someone has to have their password reset to "password" would you rather have a step for typing each character one by one or is it better to assume the person knows how to type consecutive characters together so that instead of being 8 steps to enter the new password it is just one.

|improve this answer
  • Hm ... QA cannot and does not read code. They would not know whether it would be easier for developers to deal with one or many bugs. – Job Dec 11 '10 at 13:55
0

I agree that QA should not try to guess at the nature of the relationship between bugs. If they find 5 bugs, open 5 bugs. If they prove to have a common underlying cause and fix, they can be merged, or one can be made the canonical reference and the others closed, whatever.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.