The Importance of Resolution in Bug Systems Rikard Edgren
This post was triggered by blog post Resolved as Not Repro – http://thetesteye.com/blog/2009/06/resolved-as-not-repro/
I believe that bug systems too often are used with onlý a this-project-right-now approach, where you care most about just getting all items dealt with.
This is perfectly fine for one-off type of projects, but does not work fully for software where the bug system is (one of) the most important sources regarding quality information.
Since I use a holistic-subjective approach to testing, I need to consider both now-and-then, and also me-and-everyone-else.
Testers, developers et.al will treat bugs differently if they are resolved As Designed, or Fixed, or External, or Worksforme, or Not Repro, or Invalid, or Postponed, or Won’t Fix or Duplicate.
At the end of this project, or next version, I might look again at all bugs set as Not Repro, or re-verify the most important Fixed bugs.
If there are many By Design issues, some usability folks might look into the details, and consider new approaches for the area.
Support people might search for information, and act differently depending on the solution of the related bug.
And also people that think that metrics matter, might be even more deceived, if the resolutions aren’t the correct ones.
My point is, you can’t really know how the information may be used, so do your best.
I agree that Resolution is important. But nearly everything in the bug system is important. If the bug reports are sloppy they tend to create conflict between those who are dependent on the information. If fields such as priority, severity are not entered correctly they might not be recognised directly as important. If you report on the wrong product, project, sub-component etc there is also a big chance that they are noticed too late.
As a tester, bugs are one of most important byproduct of our craft. By neglecting this important I say we do not act like proffessionals. I would not say that I am personally offended by a tester who is sloppy about bugs, but I would indeed go through with him/her a few war stories about the cost of bad bug reports.
I totally agree.
Sometimes you can hear things like “It is better with a bad bug report than no bug report at all”.
The answer is: “It is better with a good bug report than a bad bug report.”
Leaving fields at default (e.g. Priority and Severity) is probably the most common laziness.
@Rikard:
What happened with the old expression “It is better with a really good bug report than a good bug report”? 🙂