Software Testing - Defect Life Cycle

1. What is the Defect Life Cycle?

The Defect Life Cycle (or Bug Life Cycle) is the series of states that a defect goes through during its existence.
It starts when a tester finds a defect and ends when the defect is fixed and verified, or marked as not valid.

The cycle ensures defects are tracked systematically, so none are lost or ignored.


2. Stages in the Defect Life Cycle

1. New

  • What happens: Tester finds a defect and logs it into the defect tracking tool.

  • Key actions:

    • Fill in details: title, description, steps to reproduce, severity, priority, environment, and screenshots/logs.

    • Assign to the project lead or defect triage team for review.


2. Assigned

  • What happens: The project manager or lead assigns the defect to a developer.

  • Key actions:

    • Developer reviews defect details.

    • Confirms if it’s valid and worth fixing.


3. Open

  • What happens: Developer accepts the defect and starts working on a fix.

  • Key actions:

    • Debug the issue.

    • Apply code changes.

    • Update defect status after completion.


4. Fixed

  • What happens: Developer claims the issue is resolved and updates the defect status to Fixed.

  • Key actions:

    • Check in the updated code.

    • Deploy changes to the test environment for verification.


5. Retest

  • What happens: Tester re-executes the steps to reproduce using the new build.

  • Key actions:

    • Verify the fix against expected behavior.

    • Test related areas for side effects.


6. Closed

  • What happens: Tester confirms the defect is fixed and no longer occurs.

  • Key actions:

    • Update status to Closed.

    • Document closure for reporting.


7. Reopened (if needed)

  • What happens: If the defect still exists after being marked Fixed, the tester reopens it.

  • Key actions:

    • Status changes back to Open.

    • Developer works on it again.


Other Possible States

  • Rejected – Developer or lead decides it’s not a valid bug (e.g., misunderstanding of requirements).

  • Deferred – Bug is valid but will be fixed in a future release.

  • Duplicate – Similar defect is already logged.

  • Not Reproducible – Tester’s steps don’t produce the issue on the developer’s machine.


3. Typical Defect Life Cycle Flow

New → Assigned → Open → Fixed → Retest → Closed
       ↑                                 ↓
     Rejected / Deferred / Duplicate ← Reopened

4. Best Practices

  • Use clear defect descriptions to avoid back-and-forth confusion.

  • Always link defects to test cases and requirements.

  • Keep severity (impact) and priority (urgency) accurate.

  • Regularly conduct defect triage meetings to review open issues.