An example of a simple defect life cycle

This blog post is providing a practical example of what I think is a minimal defect flow, accompanied with the roles and responsibilities

In general the flow has 3 end statuses.

• Rejected - Closed: This will tell something about the quality of defects that are raised. Rejects occur most often when registering duplicates or when the desired functionality is not well understood.
• Tolerated - Closed: Defects that end in this status are defects that are known. When going to production, these are the known issues that the product will be shipped with. We need to keep them separated from the rejected and fixed defects.
• Fixed - Closed: Defects that end in this status are unambiguously fixed defects that have been found resolved.

 Some roles have been defined, regarding the defect flow

• Issuer: Anyone who registers a defect. This is not necesarily a tester.
• Tester: Someone who is trained in testing, knows the functionality of the product to be delivered and has a brief technical insight into development, infrastructure and architecture. The tester can challenge the not accepted defects and is able to retest defects in their context.
• Defect manager: Someone who has development insight and decision power to accept, not accept and assign defects. This can role often maps on a development management role. 
• Developer: A wide role for anyone who can fix defects in the code, infrastructure, parametrization or even in the design documentation. A defect does not necessarily reside only in code. A defect can also be an inconsistency in the design documentation.

On top of this it is advised to agree on SLA's on defect resolution times and agree on defect severity levels and/or priority levels. They can be combined and interrelated.
I mostly use the following basic levels:

• Urgent -  Prio 1: Defect needs a patch - testers or users are blocked and no workaround can be put in place - Patch required within 2 working days
• High - Prio 2: Defect might need a patch but a workaround can be put in place or a less substantial amount of functionality is blocked. - Update required in a week
• Medium - Prio 3: Defect needs to be resolved, but there is a workaround possible. - All defects need to be resolved before go-live
• Low - Prio 4: Cosmetic defects. - 70 percent of defects need to be resolved before go-live

Sometimes cosmetic defects increase in ranking, when for example they occur on documents that are sent out to customers.

The status flow and its description below depicts the minimum requirements for a defect flow to be implemented.

From status	Responsible	Description	To status
-	Anyone / Issuer	Anyone who finds a defect, can register it in the system. A defect has an unambiguous title, a clear description of what is expected and what is observed and is evidenced.	Open
Open	Defect manager	Assesses the opened defect and decides that the defect is valid. The defect is not yet in the pipeline of being resolved but it has been agreed with a developer to start working on, taking priorities and timelines into consideration	Accepted
Open	Defect manager	Assesses the opened defect and decides that the defect is not valid. The defect is updated with the rationale behind the disagreement.	Not accepted
Not accepted	Tester	The Tester assesses the non accepted defects and where they do not agree, they discuss with the defect manager and project manager. TOGETHER, they agree that the defect is valid and move the defect to the accepted status and directly assign it to a developer.	Accepted
Not accepted	Tester	The tester assesses the  non accepted defects and where they agree, they consult with the issuer of the defect that it can be rejected.	Closed Rejected
Accepted	Developer	The developer indicates that they start working on the defect assigned to them.	In progress
In progress	Developer	The developer agrees with the project manager that other defects get priority over this particular defect under fix. The defect fix is put on hold.	On hold
In progress	Developer	The developer indicates that the fix has been made and updates the defect with information on the fix that has been applied	Fixed
On hold	Defect manager	The defect manager or development manager propose defects that can be tolerated in the release of the software to production. The defects that are accepted by all stakeholders, move to the status closed-tolerated so that they can be addressed in a later release.	Closed Tolerated
Fixed	Defect manager	When a build or fix is released in a test environment, the defects that were fixed, will be re-testable. The defect manager updates those defects to the retest status.	Retest
Retest	Tester/issuer	Any defect to be retested is taken up by a tester to verify if the defect has been really fixed in all instances. When the defect has been partially fixed or not fixed (not when another regression defect occurs) the defect is set to the status Open with the according evidence and comments.	Open
Retest	Issuer	Any defect to be retested needs ultimately retesting of the issuer of the defect. When the fix is confirmed, the issuer brings the defect to the final status of Closed-Fixed	Closed-Fixed