Bug lifecycle: New -> Triaged -> Assigned -> In Progress -> Fixed -> Verified -> Closed.
Stages:
1. New / Reported.
- QA / user finds an issue.
- Logs in tracking tool (Jira, Azure DevOps, etc.).
- Includes: title, description, steps to reproduce, expected vs actual, environment, severity.
2. Triaged.
- Reviewed by QA lead / dev lead / product owner.
- Severity confirmed (Sev 1 critical, Sev 2 major, Sev 3 minor, Sev 4 cosmetic).
- Priority assigned.
- Routed to right team.
3. Assigned.
- Developer assigned to fix.
4. In Progress.
- Developer working on fix.
- Branch created, code being written.
5. Fixed.
- Developer commits fix; PR raised.
- Code review.
- Merged to develop / main.
- Deployed to test environment.
6. Verification (QA retest).
- QA retests with fix in test env.
- Confirms fix works; no regression.
7. Verified.
- QA marks as fixed.
8. Closed.
- Defect closed in tracking system.
- Audit log preserved.
Other states:
- Reopened: fix didn't work; defect reopened.
- Won't Fix: decided not to fix; closed without resolution.
- Cannot Reproduce: dev can't reproduce; QA provides more info or closes.
- Duplicate: matches another defect; merged.
Severity vs priority:
- Severity: technical impact (Sev 1 = system down, Sev 4 = cosmetic).
- Priority: business urgency (P1 = must fix now, P4 = next release).
A Sev 4 in customer-facing area might be P1; a Sev 1 in rarely-used area might be P3.
Senior QA insight: good defect reports are precise. Vague defects waste developer time. Reproducible steps + environment + expected vs actual save hours.
The senior framing: defect tracking is institutional memory. Future-you / future-team learns from past defects. Treat the tracker as a knowledge base.