Default Bug Workflow
The Edit, Reassign, Add Comment, and Add Workaround actions have been omitted from this diagram.
- Edit and Reassign are predefined for each state and cannot be modified. These actions do not change an issue’s state.
- Add Comment, which is defined for all states, does not change an issue’s state.
- Add Workaround, which is defined for Dev-Ready, QA-Ready, QA-Redo, and Closed, does not change an issue’s state.
Default reason codes in the bug workflow
To see all the reason codes supplied in the default bug workflow, click . Select BUG as the issue type and view its valid actions and reason codes.
Examples
Consider a common path through the default bug workflow. A bug is reported, enters the Unreviewed state, and is sent to a QA engineer’s inbox. The bug is confirmed and sent to a developer’s inbox (Dev-Ready state). The developer claims to fix the bug and takes the Fixed action. The Fixed action sends the bug to QA-Ready with the reason code Fixed. The QA engineer who receives the issue verifies that the bug has been fixed. In other words, he takes the Verify action, which sends the bug to the Closed state, retaining the Fixed reason code.
Now consider a small change in the preceding example. Say that the QA engineer rejects the developer’s claim that the bug has been fixed. The bug returns to the developer’s inbox, but this time the reason code is Rejected. The developer is unable to reproduce the problem and so takes the Need More Info action. The bug goes to QA-Redo. The QA engineer can take one of two actions to close the issue at this point—Mark as Duplicate or No Longer an Issue, or the QA engineer can clarify the problem and send the bug back to Dev-Ready.