Every bug report is a ticket on a journey. It enters the system as a raw observation, travels through a series of hands, and ideally exits as a closed, verified fix. Understanding the status flow is essential — not just because you'll live in Jira, but because tracking statuses is how the team keeps quality visible.
Learning Objectives
By the end of this lesson you will be able to:
- Describe each standard bug lifecycle status and its meaning
- Identify who is responsible for each status transition
- Explain the difference between Closed and Reopened and when each applies
The Standard Bug Lifecycle
Different teams use slightly different status names, but the underlying flow is consistent across the industry.
New (or Open)
The QA engineer files the bug. It's now in the system, assigned to nobody yet, waiting to be triaged.
Owner: QA engineer (created it), or team lead (for triage).
Assigned
The bug has been reviewed, confirmed as valid, and assigned to a developer for investigation and fixing.
Owner: Project manager, team lead, or developer (self-assignment in some teams).
In Progress
The developer is actively working on the fix.
Owner: Developer.
Fixed (or Ready for QA / Resolved)
The developer believes the fix is complete and has deployed it to the appropriate environment (staging, test, etc.). The ticket is now in the QA engineer's court.
Owner: Developer → hands off to QA.
This transition is critical. Some teams have a separate status like "Ready for QA" or "Pending Verification" between Fixed and Closed to avoid confusion.
QA Verification (or In Verification)
The QA engineer is actively verifying the fix. They follow the original reproduction steps, check edge cases, and look for regressions in adjacent functionality.
Owner: QA engineer.
Closed
The fix is verified. The behavior matches requirements. The bug is done.
Owner: QA engineer (who verifies and closes).
Reopened
The QA engineer verified the fix and the bug is still reproducible — or the fix introduced a new problem. The ticket is sent back to the developer with a note explaining what was observed.
Owner: QA engineer (reopens), Developer (receives it again).
The Lifecycle as a Diagram
NEW → ASSIGNED → IN PROGRESS → FIXED → QA VERIFICATION → CLOSED
↓
REOPENED
↓
IN PROGRESS → FIXED → ...
Special Statuses You'll Encounter
| Status | Meaning |
|---|---|
| Rejected / Not a Bug | The team decides the behavior is correct or out of scope. See Module 3, Lesson 3 for how to handle this. |
| Duplicate | The same bug was already reported. Your ticket is linked to the original and closed. |
| Deferred / Postponed | Valid bug, but fixing it is not a priority for the current release. It will be addressed later. |
| Cannot Reproduce | The developer cannot reproduce the bug with the provided steps. More information needed. |
| Won't Fix | The bug is valid but the team has decided it's not worth fixing (too rare, too low impact, or too costly to change). |
Tips for Clean Status Management
- Never close your own bugs without verification. Verification is a QA activity.
- Add a comment when reopening. Don't just flip the status — explain what you observed when you attempted verification.
- Check the environment. Before reopening, confirm you're testing on the correct build. "I tested on staging but the fix was deployed to QA environment" is a common source of confusion.
Pro Tips
Monitor "Fixed" tickets proactively. Don't wait for a developer to ping you. Check the "Ready for QA" column every morning and keep the verification queue from backing up.
Verification is not just repeating the original steps. Always do a quick sanity check around the fixed area to catch regressions.
Summary
- Bug statuses flow: New → Assigned → In Progress → Fixed → QA Verification → Closed (or Reopened).
- The QA engineer owns the Verification and Closed/Reopened transitions.
- Special statuses like Duplicate, Deferred, and Won't Fix are part of the normal lifecycle.
- Always add a comment when reopening a ticket to explain what you observed during verification.