The Defect Life Cycle and Writing Bug Reports Developers Trust
A bug that isn't reported clearly is, in a practical sense, worse than a bug that was never found. A developer can't fix what they can't reproduce, and a vague ticket, "the booking page is broken sometimes" burns hours of back-and-forth that a well-written report would have prevented entirely.
This article walks through the defect life cycle end to end, the difference between severity and priority (a genuinely common interview trap), what a great bug report contains, and how defect triage decisions actually get made.
The defect life cycle, state by state
A defect typically starts as New, the moment it's logged. It moves to Assigned once a developer or team takes ownership, then Open or In Progress while it's being actively worked. Once a fix is implemented it becomes Fixed, and moves to Retest, where the original reporter (or whoever picked it up) verifies the fix in the build where it was applied.
From there it either reaches Verified/Closed, the fix actually works or gets Reopened if it doesn't, with fresh evidence explaining why. A few branch states matter too: Rejected (not actually a defect, often a misunderstanding of expected behavior), Duplicate (already logged elsewhere), and Deferred (a real defect, but consciously postponed to a later release with sign-off). Each state transition should be backed by evidence, a status change without evidence is where trust between QA and developers starts to erode.
Severity vs. Priority - the distinction that trips people up
Severity measures technical impact on the system: does this crash the app, corrupt data, or is it a cosmetic misalignment. Priority measures business urgency: how soon does this need fixing, regardless of how technically serious it is.
The two don't always move together, and that's exactly why they're tracked separately. A misaligned logo on the page the CEO is demoing to investors tomorrow is low severity (nothing is broken) but high priority (fix it today). A backend crash that only occurs on a rare, hard-to-reach edge case might be high severity (the app crashes) but lower priority if almost no real user will ever hit that path. Confusing the two or worse, using them interchangeably is one of the fastest ways to mis-triage a defect list.
What a bug report needs to actually be useful
A title that describes the actual defect, not just the symptom in the vaguest possible terms "App crashes when applying a promo code to an empty cart on iOS Safari" is immediately actionable; "app crashes" is not. Environment details: browser or app version, OS, device, build number. Clear preconditions and numbered, minimal reproduction steps minimal meaning you've trimmed away anything not actually required to trigger the bug. Expected result versus actual result, stated explicitly and separately. Evidence: a screenshot, screen recording, or relevant log excerpt, attached every time it's available. And finally, severity and priority, set thoughtfully rather than defaulted to the same value out of habit.
How defect triage actually works
Triage is usually a short recurring meeting QA lead, relevant developers, and often a product owner reviewing new and disputed defects to confirm severity/priority and decide what gets fixed now versus later. Disagreements are normal and healthy: a developer might argue a defect is lower severity than logged because of a workaround; product might push back on priority based on upcoming roadmap plans. What keeps triage productive is that everyone is arguing from the same evidence which is exactly why a well-written original bug report matters so much before the meeting even starts.
Real-World Example
On a cleaning-service booking app, testing turns up an issue: selecting a same-day appointment slot after 6 PM doesn't grey out time slots that have already passed. A user can select and successfully book a slot at, say, 4 PM on the current day, well after that window has closed.
The report is written with the exact repro steps (device, time zone setting used, exact slots visible in the picker, screenshot of the confirmed booking with a past timestamp), and flagged as Major severity because it silently creates a booking that can never actually be fulfilled, not a cosmetic issue and P2 priority, since it's a real but comparatively rare timing window rather than something every user hits daily. Triage agreed with both ratings within the same meeting, largely because the original report already contained everything needed to make that call without follow-up questions.
Best Practices
- Reproduce a bug at least twice before logging it, to rule out environment flukes.
- Write titles that describe the actual defect and its trigger condition, not a vague symptom.
- Attach evidence, screenshot, recording, or log every single time, not just for complex bugs.
- Decide severity and priority independently before triage, rather than defaulting one from the other.
- Verify fixes in the same environment and build where the bug was originally found.
- Retest and formally close the loop don't let a ticket sit as "probably fixed" indefinitely.
Common Mistakes to Avoid
- Mistake: Vague titles and steps ("booking page is broken")
Fix: State the exact trigger condition and observed result in the title itself. - Mistake: Assuming the developer can reproduce it from a one-line description
Fix: Write numbered, minimal repro steps as if the reader has never seen the feature. - Mistake: Conflating severity and priority
Fix: Assign them independently, based on technical impact and business urgency respectively. - Mistake: Reopening bugs without new evidence
Fix: Attach fresh proof, screenshot or log from the retest explaining specifically why the fix didn't work. - Mistake: Marking a defect closed based on the developer's word alone
Fix: Always retest and verify in the actual build before moving a defect to Closed.
Key Takeaways
- A bug report is a communication artifact aimed at a developer who wasn't there when you found it, write it that way.
- Severity is about technical impact, priority is about business urgency, and they don't always move together.
- The defect life cycle only holds up if every state change is backed by evidence, not assumption.
- Good bug reports save round-trips and build trust, sloppy ones cost both.
- Triage decisions are only as good as the evidence in the original report.
