Software Testing Bug Lifecycle

The bug lifecycle (also called the defect lifecycle) is the journey a bug travels from the moment it is discovered to the moment it is closed. Every bug follows a defined set of states and transitions managed by the testing and development team.

Why the Bug Lifecycle Matters

Without a defined lifecycle, bugs get lost, forgotten, re-opened without tracking, or fixed without verification. The lifecycle creates accountability — every bug has a current owner, a current state, and a clear next step.

The Bug Lifecycle Diagram

  ┌──────────┐
  │   NEW    │ ← Tester finds and reports the bug
  └────┬─────┘
       │
       ▼
  ┌──────────┐
  │ ASSIGNED │ ← Test Lead assigns it to a developer
  └────┬─────┘
       │
       ▼
  ┌──────────┐      ┌──────────────┐
  │   OPEN   │ ───► │  REJECTED    │ ← Developer says: not a bug
  └────┬─────┘      └──────────────┘
       │
       ▼
  ┌──────────┐      ┌──────────────┐
  │  FIXED   │ ───► │  DEFERRED    │ ← Fixed later, not this release
  └────┬─────┘      └──────────────┘
       │
       ▼
  ┌──────────┐
  │  RETEST  │ ← Tester verifies the fix
  └────┬─────┘
       │
     ┌─┴────────────┐
     ▼              ▼
  ┌──────────┐  ┌──────────┐
  │  CLOSED  │  │ REOPENED │ ← Fix did not work, cycle repeats
  └──────────┘  └──────────┘

Bug States Explained

New

The tester has discovered and documented a new defect. The bug report is submitted to the bug tracking system. At this point, no one has reviewed or acted on it yet.

Assigned

A test lead or project manager reviews the bug and assigns it to the relevant developer. The developer is now responsible for investigating it.

Open

The developer has started working on the bug. The defect is actively being investigated and fixed.

Rejected

The developer reviews the bug and concludes it is not a valid defect. Reasons for rejection include: working as designed, not reproducible, duplicate of another bug, or unclear steps to reproduce. The tester may challenge the rejection if they disagree.

Deferred

The bug is valid but will not be fixed in the current release. It is scheduled for a future version. This happens when the fix is too risky, too time-consuming, or lower priority than the current schedule allows.

Fixed

The developer has applied a fix and updated the bug report. The bug moves to the tester for verification.

Retest

The tester runs the original test case again to verify whether the fix works correctly. This is also called retesting or verification testing.

Reopened

The fix did not work, or the fix introduced a new problem. The tester reopens the bug and it cycles back to the developer.

Closed

The tester confirms the fix works correctly. The bug is closed. Closure is final only after successful verification.

Writing a Good Bug Report

A well-written bug report saves hours of back-and-forth between testers and developers. Every bug report should include:

  ┌─────────────────────────────────────────────────────────┐
  │ Bug ID:          BUG-0042                               │
  │ Title:           Login fails with valid credentials     │
  │ Module:          Authentication                         │
  │ Severity:        Critical                               │
  │ Priority:        High                                   │
  │ Reported By:     Tester Name                            │
  │ Date:            2024-03-15                             │
  │                                                         │
  │ Environment:     Chrome 122, Windows 11, Staging server │
  │                                                         │
  │ Steps to Reproduce:                                     │
  │   1. Open https://staging.app.com/login                 │
  │   2. Enter email: user@test.com                         │
  │   3. Enter password: ValidPass@1                        │
  │   4. Click "Login" button                               │
  │                                                         │
  │ Expected Result: User is redirected to dashboard.       │
  │ Actual Result:   "Invalid credentials" error appears.   │
  │                                                         │
  │ Attachments:     screenshot.png, console_log.txt        │
  └─────────────────────────────────────────────────────────┘

Bug Severity vs Bug Priority

  SEVERITY                         PRIORITY
  ────────                         ────────
  Impact on software function      Urgency of fixing it

  Critical: System crashes          High: Fix before release
  Major: Feature completely broken  Medium: Fix in this sprint
  Minor: Feature partially broken   Low: Fix when time allows
  Trivial: Cosmetic/UI issue        Very Low: Next release

  Example:
  ─────────────────────────────────────────────────────────
  Bug: CEO's name is misspelled on the About page
  Severity: Trivial (no functional impact)
  Priority: High (CEO must see fix before tomorrow's launch)

  Bug: Search returns results 2 seconds slower than usual
  Severity: Minor (still works)
  Priority: Low (not blocking anything)

Common Bug Tracking Tools

  • Jira: The most widely used tool in the industry. Supports full bug lifecycle management with custom workflows.
  • Bugzilla: An open-source bug tracker used by many open-source projects.
  • Trello: A simpler card-based tool used by smaller teams for lightweight bug tracking.
  • Azure DevOps: Microsoft's platform that integrates bug tracking with code and deployment pipelines.
  • Mantis: A straightforward open-source tool popular in mid-sized teams.
Previous lessons
Back to courses
Next lessons

Leave a Comment