The Life Cycle of a Bug: Stages, Roles, and Best Practices

The life cycle of a bug is the structured process a defect follows from its detection to its final resolution. Each stage involves specific actions and clearly defined roles to ensure efficient management and an effective solution. Below, I detail each phase in greater depth, including best practices and alternative flows.

1. New (New)

Responsible: Tester or QA Engineer
Description:
The tester identifies unexpected or inconsistent behavior during test execution (manual or automated) and reports it in the bug tracking system.

Key Actions:
✔ Detailed documentation:

  • Exact steps to reproduce the defect.
  • Test environment (browser, OS, software version, etc.).
  • Expected behavior vs. actual behavior.
  • Screenshots, logs, or videos if relevant.

✔ Bug classification:

  • Priority (Urgent, High, Medium, Low): Impact on the business or user.
  • Severity (Critical, Major, Medium, Minor): Degree to which the system is affected.

✔ Initial assignment:

  • The bug is logged as “New” and assigned to the development lead or project manager for review.

2. Assigned (Assigned)

Responsible: Development Lead or Project Manager
Description:
The bug is evaluated to determine its validity and assigned to the corresponding developer.

Key Actions:
✔ Initial validation:

  • Confirm if the bug is reproducible and not duplicated.
  • Verify if it is a real defect or a misunderstanding (e.g., configuration error).

✔ Possible decisions:

  • Accept: Assign to the developer for correction.
  • Reject: If it is not a valid bug (e.g., expected behavior, user error).
  • Defer: If it is not critical and will be addressed in a future iteration.

3. Active (Active / In Progress)

Responsible: Developer
Description:
The developer investigates and corrects the defect.

Key Actions:
✔ Root cause analysis:

  • Review the code, logs, and related flows.
  • Identify if the error is from the development itself, integration, or an external component.

✔ Solution development:

  • Implement the fix and test it locally.
  • Ensure it does not introduce new defects (unit tests).

✔ Status update:

  • Document the changes made in the tracking system.

4. Fixed (Fixed / Resolved)

Responsible: Developer
Description:
The developer confirms the bug has been corrected and sends it for verification.

Key Actions:
✔ Push changes to the repository:

  • Make a commit with a clear description (e.g., “Fix #123: Correction of tax calculation error”).
  • Merge into the corresponding branch (develop, main, etc.).

✔ Mark as “Fixed” in the system:

  • Indicate the version where the fix was applied.
  • Provide additional details if the tester needs to validate something specific.

5. Verified (Verified / Closed)

Responsible: Tester
Description:
The QA verifies that the fix is effective and does not cause regressions.

Key Actions:
✔ Regression testing:

  • Validate the original bug scenario.
  • Ensure that related functionalities are not affected.

✔ Possible outcomes:

  • Success: The bug moves to “Closed” status.
  • Failure: It is reopened and returned to “Active” with detailed comments.

6. Closed (Closed)

Responsible: Tester or QA Lead
Description:
The bug is permanently closed upon confirming its resolution.

Key Actions:
✔ Final documentation:

  • Log evidence of the successful test.
  • Update project quality reports.

✔ Archiving:

  • The bug remains as a reference for future audits or analysis.

7. Rejected (Rejected)

Responsible: Development Lead or QA Manager
Description:
The bug is discarded for not being valid (duplicate, not reproducible, user error, etc.).

Key Actions:
✔ Clear justification:

  • Example: “Not a defect, the behavior is as expected per requirement X.”

✔ Communication with the tester:

  • If the bug was misinterpreted, the scenario is clarified to avoid similar reports.

Alternative Flows and Considerations

🔄 Reopening a Bug

  • If the fix does not work, the bug returns to “Active” with detailed observations.
  • If the same defect is found in another area, a new report is created and linked to the original one.

⚠ Duplicate or Invalid Bugs

  • They are marked as “Rejected” or “Duplicate” and linked to the main bug.

🛠 Best Practices ✔ Constant communication between Devs and QA to avoid misunderstandings.
✔ Tracking with tools like Jira, Azure DevOps, or Bugzilla to maintain traceability.
✔ Retrospectives to analyze recurring bugs and improve processes.

Conclusion A well-managed bug life cycle improves software quality, optimizes the team’s time, and facilitates the delivery of more stable products. The key lies in clear documentation, collaboration between roles, and the use of appropriate tools.