Bug Life Cycle

Go back to Tutorial

Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime. It varies from organization to organization and also from project to project as it is governed by the software testing process and also depends upon the tools used.

Defect Life Cycle States

• New – Potential defect that is raised and yet to be validated.
• Assigned – Assigned against a development team to address it but not yet resolved.
• Active – The Defect is being addressed by the developer and investigation is under progress. At this stage there are two possible outcomes; viz – Deferred or Rejected.
• Test – The Defect is fixed and ready for testing.
• Verified – The Defect that is retested and the test has been verified by QA.
• Closed – The final state of the defect that can be closed after the QA retesting or can be closed if the defect is duplicate or considered as NOT a defect.
• Reopened – When the defect is NOT fixed, QA reopens/reactivates the defect.
• Deferred – When a defect cannot be addressed in that particular cycle it is deferred to future release.
• Rejected – A defect can be rejected for any of the 3 reasons; viz – duplicate defect, NOT a Defect, Non Reproducible.

Defect Life Cycle in Detail

• Tester finds the defect
• Status assigned to defect- New
• A defect is forwarded to Project Manager for analyze
• Project Manager decides whether a defect is valid
• Here the defect is not valid- a status is given “Rejected.”
• So, project manager assigns a status rejected. If the defect is not rejected then the next step is to check whether it is in scope. Suppose we have another function- email functionality for the same application, and you find a problem with that. But it is not a part of the current release when such defects are assigned as a postponed or deferred status.
• Next, the manager verifies whether a similar defect was raised earlier. If yes defect is assigned a status duplicate.
• If no the defect is assigned to the developer who starts fixing the code. During this stage, the defect is assigned a status in- progress.
• Once the code is fixed. A defect is assigned a status fixed
• Next, the tester will re-test the code. In case, the Test Case passes the defect is closed. If the test cases fail again, the defect is re-opened and assigned to the developer.
• Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order that was fixed and assigned a status closed. During the second upgrade release the same defect again re-surfaced. In such cases, a closed defect will be re-opened.

Guidelines

• Make sure the entire team understands what each defect status exactly means. Also, make sure the defect life cycle is documented.
• Ensure that each individual clearly understands his/her responsibility as regards each defect.
• Ensure that enough detail is entered in each status change. For example, do not simply DROP a defect but provide a reason for doing so.
• If a defect tracking tool is being used, avoid entertaining any ‘defect related requests’ without an appropriate change in the status of the defect in the tool. Do not let anybody take shortcuts. Or else, you will never be able to get up-to-date and reliable defect metrics for analysis.

Go back to Tutorial