共用方式為

Resolving Resolutions

  • 發行項

Anu asks:

[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:

  • By Design. "That's not a bug, it's a feature!" has been parodied to death, but occasionally it is the truth. If you peruse the specification closely enough you will find that what you thought was a bug is indeed correct behavior. (What's that? You don't have a spec? Then everything is a bug!) If you believe the specification is wrong, then log a spec bug. As it is, the application is working correctly.
  • Duplicate. An existing bug already covers this issue. As Anu indicates, the definition of "this issue" is not always clear. In my view, closing a bug as a dupe of another bug requires both defects to clearly be the result of the same root cause. If this is not the case then both bugs should stay open, even if a single code change will fix both. When closing a bug I always verify that any dupes of the bug I am closing are fixed as well. Sometimes a "duplicate" bug turns out to still repro, usually because the now-fixed bug was hiding one or more additional bugs.
  • External. The bug is not in our code but rather in a component we get from somewhere else. Log a bug with the responsible team. Many teams leave External bugs resolved-but-not-closed until a new (fixed) version of the dependency has been provided and the fix verified.
  • Fixed. The source of the bug has been identified, a fix has been checked in, and the repro steps listed in the bug report now produce the expected results.
  • Not Repro. The repro steps listed in the bug report produce the correct results, not the reported incorrect behavior. Note that this is *not* the same as "Well it works on my machine!", which can often be translated as "It works on a different operating system running a different language using a debug build from three weeks after the bug was reported". Resolving a bug as Not Repro involves executing exactly the steps listed in the bug report on exactly the same configuration using exactly the same build. Once you've done that, you can try executing the steps on a current build. If the bug does not repro on the current build, it was (perhaps accidentally) Fixed in the interim. Thorough developers and testers will search through the intervening builds to determine when the bug stopped reproducing, and then search through the checkins for that build to determine why it stopped reproducing.
  • Postponed. Resolving a bug Postponed is a statement that the team believes the defect should be fixed at some point in the future, but that it will not be fixed in the current version. Postponed bugs are typically bulk reactivated and reevaluated once you ship the current version.
  • Won't Fix. A Won't Fix'd bug will never ever ever be fixed.

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!

Comments

  • Anonymous
    January 07, 2007
    Re the Not Repro section: If your testing team is a bit 'under-resourced', then you can't be a thorough tester. In this scenario you would accept that the bug has been fixed without worrying about exactly when. Time spent worrying about that is put to better use by chasing down other bugs.

  • Anonymous
    January 07, 2007
    Some related Discussion .... http://shrinik.blogspot.com/2006/09/bug-or-feature.html Shrini