Defect Workflow and States

Defect Workflow and States

We generally use JIRA or Devops Azure to manage defect reports through the defect lifecycle. A defect report typically progresses through a workflow and moves through a sequence of states as it continues through the defect lifecycle. In most of these states, a single defect lifecycle participant owns the report and is responsible for carrying out a task which, when completed, will cause the defect report to be moved to the next state (and assigned to the next responsible party). In terminal states, such as when the defect report is closed (usually meaning that the underlying defect is fixed and the fix verified through a confirmation test), canceled (usually meaning that the defect report is invalid), irreproducible (usually meaning that the anomaly can no longer be observed), or deferred (usually meaning that the anomaly relates to a real defect, but that defect will not be fixed during the project), the report does not have an owner, because no further actions are required.
For defects discovered by testers during testing, there are three states in particular where the action resides with the test team:

  • The initial state
    • In this state, one or more testers gather the information necessary for the person
    • responsible for resolving the defect to reproduce the anomaly. o This may also be referred to as the “open” or “new” state.
  • The returned state
    • In this state, the receiver of the report has rejected the report or is asking the tester to supply further information. This state may indicate a shortfall in the initial information- gathering process or of the testing itself, and Test Managers should monitor for excessive rates of return. The tester(s) must provide the additional information, or confirm that the report indeed should be rejected.
    • This may also be referred to as the “rejected” or “clarification” state.
  • The confirmation test state
    • In this state, the tester will run a confirmation test (often following the steps to reproduce the failure from the defect report itself) to determine whether the fix has indeed solved the problem. If the confirmation test indicates that the defect is repaired, the tester should close the report. If the confirmation test indicates that the defect is not repaired, the tester should re-open the report, causing it to be reassigned to the previous owner, who can then complete the work necessary to repair the defect.
    • This may also be referred to as the “resolved” or “verification” state.