Bug Tracking – Possible Resolution States
I have used multiple bug tracking systems. Most have support for a basic lifecycle that works in most cases. When a bug is resolved, there is varied support for how the bug was resolved. For example, FogBugz, for a bug, has the following resolved states:
- Resolved (Fixed)
- Resolved (Not Reproducible)
- Resolved (Duplicate)
- Resolved (Postponed)
- Resolved (Won’t Fix)
- Resolved (By Design)
Bugzilla uses the following resolution reasons:
- Fixed
- Duplicate
- Won’t Fix
- Works For Me
- Invalid
Jira has the following default resolutions:
- Fixed
- Won’t Fix
- Duplicate
- Incomplete
- Cannot Reproduce
As you can see, among these three products, most of the resolution states are supported across these various bug tracking solutions.
When I was at Aldus, we had a set of resolutions which gave more detail as to why a bug was not fixed. I still find myself referencing these abbreviations (and ones I added) when I am working with bugs:
- Fixed
- DUP – Duplicate
- CNR – Cannot Reproduce
- NAB – Not a Bug
- NOB – Not Our Bug
- NLAB – No Longer a Bug
- NTBF – Not to be Fixed
A resolution of DUP should reference the appropriate ID(s) of the bugs which this one duplicates. NAB should state why – by design, misunderstanding, etc. NOB is useful when using components from other vendors and the decision is made not to work around an issue in the component. NOBs should be reviewed periodically to see if fixes are available from the component vendor. NLAB occurs when a feature is descoped or reworked so the bug is no longer applicable to the product. Finally, NTBF is used to remove the bug from the active list. NTBFs from prior releases should be reviewed at the beginning of a project. In addition, NTBF bugs in the current release need to be reviewed periodically to make sure the resolution is not being used too aggressively.