The complete journey a bug takes from discovery through closure - a formal tracking process.
Bug lifecycle is important for tracking, accountability, and understanding quality trends. Each stage has clear criteria and responsibilities. Organizations use bug tracking tools (Jira, Azure DevOps, Bugzilla) to automate this workflow.
| Stage | Description | Action | Entry Criteria | Exit Criteria | Tester Responsibility | Developer Responsibility |
|---|---|---|---|---|---|---|
| New/Open | Bug is discovered by tester and formally reported | Tester creates bug ticket with detailed information | Tester found unexpected behavior | Bug report is complete and assigned | Write clear steps to reproduce, expected vs actual result | |
| Assigned | Bug is assigned to developer to analyze and fix | Developer analyzes root cause and plans fix | Bug is valid and verified by QA lead | Developer completes code changes | Understand bug, implement fix, update ticket status | |
| Fixed/Resolved | Developer claims the bug is fixed in code | Developer moves bug to 'Fixed' status | Code changes are committed | QA starts re-testing | Provide build version where fix is included | |
| Closed | QA verifies the fix works. Bug is permanently closed. | QA closes the ticket | Fix verified by QA tester | Bug no longer exists | Test with exact steps reported, verify fix, close ticket | |
| Reopened | Fix doesn't work or new related issues found | QA reopens ticket and reassigns to developer | During re-testing, issue still exists or new issue found | Reassigned to developer for investigation | Document why fix didn't work, provide additional details |
New → Assigned → Fixed → Closed (✓) OR Reopened → Assigned → ... (loop continues until fixed)
How badly does this bug impact the system? Impact assessment.
QA Tester (the person who found the bug)
| Level | Description | Example |
|---|---|---|
| Critical | System crashes, data loss, security breach, core functionality broken | User loses all order history after payment |
| High | Major feature doesn't work as intended | Discount not applied in checkout |
| Medium | Feature partially works or minor workaround exists | Search results show in wrong order |
| Low | Cosmetic issue, doesn't affect functionality | Button text is misaligned |
How urgently should this be fixed? Business decision.
QA Lead or Product Manager
| Level | Description | Example |
|---|---|---|
| Critical | Fix immediately, blocks release | Payment module broken |
| High | Fix before next release | Important feature incomplete |
| Medium | Fix in reasonable time | Minor bugs affecting usability |
| Low | Can defer to future release | Nice-to-have fix, low impact |
| Scenario | Severity | Priority | Why |
|---|---|---|---|
| Red button appears as green | Low (cosmetic, no functionality impact) | High (company branding affected) | Severity = how bad technically, Priority = how bad for business |
| App crashes when user types Chinese characters | Critical (app crashes = complete loss of function) | Medium (affects only users who type Chinese, not all users) | Severity = affects everyone, Priority = affects specific user segment |
| 404 page font is Comic Sans instead of Arial | Low (cosmetic) | Low (user rarely sees this) | Both low because minimal impact |
Bug: Users can see other users' payment methods
Critical (security issue, data exposure)
Critical (legal liability, must fix before release)
1. New: Found during UAT. 2. Assigned: Developer assigned. 3. Fixed: Code fix committed. 4. Closed: QA verified fix. 5. Reverified: Retest across all browsers. 6. Released: Fix in production hotfix.
Good bug reports have:
You find a bug where the app crashes when uploading a file >100MB. You need to report it. How would you determine Severity and Priority?
🐛 Severity = How bad? Priority = How urgent? Critical bug with low priority can wait. Spelling error with high priority gets fixed ASAP.
Interviewers test understanding of severity vs priority distinction and how to write good bug reports.