Bug Life Cycle and Defect Reporting

A defect moves through a predictable set of states from discovery to resolution, and a clear, well-written bug report is essential for that process to move smoothly.

The Bug Life Cycle

While specific tools use slightly different terminology, most defect life cycles follow a similar path from initial discovery through to closure.

• New — a defect has just been reported.
• Assigned — a developer has been assigned to investigate.
• In Progress / Fixed — a fix has been implemented.
• Retest — a tester verifies the fix resolves the issue.
• Closed — the fix is confirmed and the defect is resolved.
• Reopened — the fix didn't fully resolve the issue, and it goes back for further work.

Writing a Good Bug Report

A clear bug report should include exact steps to reproduce, the expected result, the actual result, environment details (browser, OS, device), and a severity/priority rating — everything a developer needs to understand and fix the problem without a lengthy back-and-forth.

Common Mistakes

• Writing a vague bug report like "the page is broken" with no reproduction steps.
• Confusing severity (how serious the impact is) with priority (how urgently it needs fixing) — a low-severity bug can still be high priority, and vice versa.
• Forgetting to include environment details, making a browser- or device-specific bug hard to reproduce.
• Not verifying a fix thoroughly before closing a defect, allowing it to be reopened later.