The bug life cycle and how to report a defect
How a bug travels from New to Closed (and the detours like Reopened, Rejected, Deferred, Duplicate), severity vs priority explained with examples, and how to write a defect report a developer can actually act on.
When you find a bug, it doesn't just vanish into a developer's brain and reappear fixed. It travels through a series of well-defined stops (a life cycle), and at each stop a different person decides what happens next. Understanding that journey turns you from someone who spots bugs into someone who drives them to a fix, which is the whole point.
The journey of a bug
Here's the main highway most bugs travel. The states have slightly different names in different tools, but the shape is universal:
New
you logged it
Assigned
given to a dev
Open
dev working
Fixed
dev done
Retest
QA re-checks
Verified
fix confirmed
Closed
done
That's the happy path. But bugs take detours, and the detours are where the real life of defect management happens:
- Reopened: you retested the "fixed" bug and it's still broken (or broke again). Back to the developer it goes.
- Rejected: the developer says it's not actually a bug, maybe it's working as designed. Sometimes they're right; sometimes you need to make your case better.
- Deferred: it's a real bug, but it'll be fixed later (low priority, or a future release). Logged, acknowledged, parked.
- Duplicate: someone already reported this one. It gets linked to the original and closed.
When a bug is Rejected or marked Duplicate, don't take it personally. It usually means the report could have been clearer, or a quick search would have found the twin. Both are fixable habits, and getting them right makes developers trust your reports.
Severity vs. priority: not the same thing
This pair confuses almost every beginner, so let's nail it. Severity is how badly the bug damages the software: a technical judgement, usually the tester's call. Priority is how urgently it should be fixed: a business judgement, usually the manager's or product owner's call. They often line up, but the interesting cases are when they don't.
| Example bug | Severity | Priority | Why |
|---|---|---|---|
| App crashes when you open Settings | High | High | Badly broken and blocks people right now. |
| Company name misspelled on the home page logo | Low | High | Technically trivial, but embarrassing and very visible. Fix it today. |
| Crash in a rarely-used admin export from years ago | High | Low | Serious if it happens, but almost nobody hits it, so it can wait. |
| Button is two pixels off on one screen | Low | Low | Minor and barely noticeable. Fix it when convenient. |
Severity = how much it hurts the software. Priority = how soon the business needs it fixed. A typo in the logo is low severity but high priority. A crash in a feature nobody uses is high severity but low priority. Keeping them separate stops a lot of pointless arguments.
How to write a bug report a developer can act on
A bug nobody can reproduce rarely gets fixed. Your report's only job is to let someone else see exactly what you saw, fast. A great report has these parts:
- 1
A clear, specific title
'Checkout button does nothing on Safari when the cart is empty', not 'checkout broken'. The title alone should tell the team what and where.
- 2
Steps to reproduce
Numbered, exact, starting from a known point. Anyone should be able to follow them and hit the same wall. This is the single most valuable part of the report.
- 3
Expected vs actual result
What you expected to happen, then what actually happened. The gap between them is the bug.
- 4
Environment
Browser and version, device, operating system, the account or test data used. A bug that only happens on one browser is hopeless to chase without this.
- 5
Evidence
A screenshot, a screen recording, the error message, console logs. Show, don't just tell. It saves a dozen back-and-forth messages.
Add severity and priority, link any duplicates, and you've written something a developer can pick up cold and fix without a single clarifying question. That's the gold standard, and it's why teams in trackers like JIRA template these fields rather than leaving them blank.
+What is the difference between an error, a defect, and a failure?
- Bugs travel a life cycle: New, Assigned, Open, Fixed, Retest, Verified, Closed, with detours through Reopened, Rejected, Deferred, and Duplicate.
- Severity is how badly it breaks the software; priority is how urgently the business needs it fixed. They are not the same.
- A typo in the logo can be low severity but high priority; a crash nobody hits can be high severity but low priority.
- A great bug report has a specific title, exact steps to reproduce, expected vs actual, environment, and evidence.
- Steps to reproduce are the most valuable part: a bug no one can reproduce rarely gets fixed.