The Bug Lifecycle: Triage, Severity vs Priority
No matter how well a team tests, some problems get through — that's normal. When something's wrong, it becomes a bug report that travels a predictable path: reported, triaged, fixed, verified, closed. And two words decide what gets fixed first — severity (how bad) and priority (how urgent) — which sound alike but mean different things.
A bug is simply software behaving differently from how it should. Tracking bugs through a clear lifecycle is how teams keep them from being forgotten or fixed in a panic.
A hospital emergency room is the right picture: incoming patients are triaged — sorted by how serious and how urgent they are, which aren't always the same — so the most important cases are handled first.
The Bug Lifecycle
A bug moves through a series of states, and most teams track it on a board. The exact names vary, but the shape is consistent: it's reported, looked at and accepted (or not), worked on, fixed, checked, and closed — and it can be reopened if the fix didn't hold.
| State | What's happening |
|---|---|
| New / reported | Someone has logged the bug |
| Triaged | Confirmed and prioritized (or declined) |
| In progress | A developer is fixing it |
| Fixed | The change is made, awaiting check |
| Verified / closed | Confirmed gone, and closed (or reopened) |
Severity vs Priority
These two get mixed up constantly. Severity is how bad the bug's impact is — does it crash the app, or just misalign a button? Priority is how urgently it should be fixed relative to everything else. They're independent: a glaring typo on the homepage is low severity (nothing breaks) but high priority (everyone sees it, it looks terrible). A rare crash deep in an unused feature might be high severity but low priority. Impact and urgency are different questions.
Triage
Triage is the regular process of going through new bugs and deciding what to do with each: fix it now, fix it later, or won't fix at all. Not every bug gets fixed — some are too minor, too rare, or not worth the cost, and "won't fix" is a legitimate, deliberate decision. Triage is where severity and priority get assigned and the team agrees what actually deserves attention.
Regression
A regression is an old bug that comes back, or something that used to work and now doesn't — often broken by a recent change. Regressions are exactly why teams keep their test suites around and growing: when a bug is fixed, a team typically adds a test for it, so that specific bug can never silently return. The growing test suite is the team's memory of every mistake it has already learned from.
On Cadence, a user reports that a reminder fired an hour late. The team triages it: it's high severity (a late reminder defeats the whole feature) but, since only a few users in one time zone hit it, medium priority. They fix it, verify it's gone, and — crucially — add a new regression test for that exact case, so this particular bug can never quietly come back. The lifecycle, severity, priority, and regression, all in one small story.
- "Severity and priority are the same thing." Severity is how bad the impact is; priority is how urgently to fix it. A low-severity typo can be high-priority, and a high-severity rare crash can be low-priority.
- "Every reported bug must be fixed." Triage means some bugs are "won't fix" — too minor, too rare, or not worth the cost. Deciding not to fix is a legitimate, deliberate call.
- "Once a bug is fixed, it stays fixed." Regressions bring old bugs back when later changes break them — which is exactly why teams keep and grow a test suite that guards against their return.
- "Sev 1", "triage", "regression", and "repro steps" are everyday team vocabulary — this decodes how real teams decide what to fix and when.
- Separating severity from priority is a genuinely useful mental tool that prevents the common mistake of treating "bad" and "urgent" as the same.
- Understanding regression explains why test suites only grow — every fixed bug leaves behind a test, so the team never relearns the same mistake.
Knowledge Check
What is the difference between severity and priority?
- Severity is how bad the impact is; priority is how urgently to fix it
- They mean the same thing and are always equal for any given bug
- Severity is how urgent it is; priority is how bad the impact is
- Severity is about who reported it, and priority is which developer fixes it
A glaring typo on the homepage breaks nothing but everyone sees it. How is it classified?
- Low severity but high priority — nothing breaks, but it's very visible
- High severity, because any visible typo is a serious crashing bug
- Low severity and also low priority, so it can safely be ignored forever
- Both must always be exactly equal, so it is medium on both scales
What is triage?
- Going through new bugs and deciding to fix now, later, or not at all
- Writing the code change that actually repairs each individual bug
- Deploying the finished software with all of its bug fixes out to the users
- Deciding which brand-new features the product should build next
What is a regression?
- An old bug that comes back, or working behavior a change has broken
- A new feature added to the product for the very first time
- A slowdown in how fast the finished program runs for users
- The whole process of deciding which bugs are actually worth fixing at all
Why do teams add a test when they fix a bug?
- So that exact bug can never silently come back as a regression
- So the code in that area will never need to be touched ever again
- So the finished program will run noticeably faster for its users
- So the team will never have to write any more new code at all
You got correct