[C]ould you post an entry on when to resolve a bug as "Dupe" or "No repro". I've been following the rule of resolve a bug as dupe if and only if the repro steps of the 2 bugs are the same. If they are the same root cause, it totally depends on the context whether you can resolve them as dupe or not. Many times, I see devs mark 2 bugs as dupe because of a large root issue. Something like "nested classes not working fine in scenario A" causes 15 bugs on different nested classes scenarios to be resolved as "Dupe"!!! At that rate, we might as well have a giant bug called "compiler not coded fully" and then resolve all bugs in the world as dupes of that!
Scenario #2. Bugs resolved as not repro because it does not repro on the dev's machine which has a build which is 10 days newer than the build that it was filed on. Errr - how is this not repro? The justification offered is, "I might have fixed this as part of a larger checkin for another bug fix...it is not reproing on a newer build now. So, no repro." How does that become a no repro?
I think this still happens because there are no clear guidelines on how to resolve bugs. I was hoping that you would either point me to a doc that outlines this or make a post yourself. Thanks for listening to the rant! :-)
Anu's rant is unfortunately not uncommon. The status with which a bug is resolved can be a contentious issue. In the worst case, developers do everything they can to resolve a bug without having to muck about in code, and testers do everything they can to keep the bugs they opened active. Even in the best case, when developers and testers have a fantastic relationship, there may be disagreement regarding how to resolve a bug.
The only way around this I know is to have the discussion and make a decision that everybody accepts. (Note that this does not mean everybody *agrees* with the decision! Merely that they can live with it.) If each member of the discussion has a common understanding of the terms involved the discussion tends to be more fruitful and come to a close more rapidly. Here are the terms we use on my team, and what I understand them to mean:
Use this list as a starting point for deciding what bug resolutions you will use on your team, and what they will mean. Be patient with your team as y'all get used to the new terminology. And then be prepared for continued disagreements (although likely fewer of them); just because your team agrees on definitions for bug resolutions does not mean that every case will clearly fit exactly into one of them!