Configuration Management
Issue Tracking
Issue Reports
|
Transition States
(and what they mean)
| Definition: State indicates a fixed point in the life-cycle of
an issue. |
| State |
Notes |
| New |
- All issues enter through this point.
- The
main purpose of 'New' is to ensure that bugs can be entered by anybody, but only after normalization, dupe-check, and proper conventions are followed do they go to
other state values.
- Bugs leave "New" by going through 'Triage/Review'
- No bug should stay in this state for long
(more than 24 hours).
|
Unclear
Issue |
- Indicates that the bug is not documented enough
for a developer to work on fixing it.
- This indicates it has been reviewed, but more communication is
needed.
- It can also mean that a decision on the issue has not yet been made
by the Producers.
- Fundamentally, it means the developer does not know what to do to
act upon the issue yet.
|
| Open |
- The normal state for all unresolved issues that need to be addressed
by Developers, Packagers, or Documentation.
- Note that the order in which the Open issues gets addressed is
determined by Priority.
- This is the primary state from which developers perform their work.
- Developers push the issue to "Build" if a build is required to
see the results.
- Developers push the issue to "Validate" in cases of user-error
and/or misunderstanding... anything where the tester does not need
to wait for another build to accept the issue into their queue.
|
| Build |
- The developer has made whatever change/fix is required to address
the issue.
- The tester will not be able to see/test the issue until it shows up
in the next posted build.
- The tester still "owns" the issue at this point, but they know it
cannot be tested just yet.
- All items in "Build" get migrated to "Test" when a build is posted.
|
| Validate
|
- Required work has been completed, checked into
the VCS, and is available to test via the latest build.
- This is the primary state from which Testers perform their work.
- It is not OK to use "fixed" as a state name because it is ambiguous between whether the developer fixed the issue, and is waiting for test, or whether the tester validated the issue, and it is actually closed.
|
Partially
Validated |
- The issue has been tested by the Tester, but cannot yet be closed
for a number of reasons.
- This state means the developer's fix has been provisionally tested,
and still requires additional QA time before it can be closed.
- It is a way to keep track of issues a tester has worked on, but not
yet finished.
- Any issue which is high risk, or which alternates between
fixed/broken, should be set to Partially Validated as a means of
ensuring that one final check on that issue occurs before closing it for
shipment.
|
Unclear
Test |
- Indicates that the bug is not documented enough
for a tester to validate it.
- This is common when a developer fixes
an issue and the tester does not have a full understanding of what
changed.
- The developer is responsible for providing additional test
information and/or resources.
- Note: This is intended to be a more accurate reflection of
the state of the issue.
It is NOT a substitute for direct, one-on-one
communication between the Tester and the Developer.
|
| Closed |
- All work on the issue has stopped.
- This
makes no mention of why or how (which would be 'Resolution').
- 'Closed' indicates that the issue is no longer demanding of anyone's
time.
- Only a regressed issue should pop an issue out of 'Closed' to
any of the other states.
|
Contact Primary Goals for a detailed review of your issue tracking system, or for consultative assistance to ensure that you have a smooth deployment of your CM system.
|
