Severity vs Priority + the Bug Lifecycle

Two questions decide every bug's fate: how bad is it, and how soon should someone fix it? They sound like one question — and they are not, which is why "severity versus priority" is the most reliably asked trap in junior QA interviews. A typo in the company name on the homepage is trivially severe and urgently prioritized. Get that example into your head and the trap never catches you again; this page makes sure of it, then walks the full journey a bug travels from filed to closed.

Severity: How Bad, Technically

Severity measures technical impact: what breaks, how completely, for how many users. Typical scale: blocker (nothing works — checkout is down), critical (a core function fails with no workaround — payments fail for one card type), major (significant function wrong, workaround exists — FW-312's shifted dates), minor (small function wrong — a fee displays with the wrong rounding), trivial (cosmetic — misaligned icon). Severity is judged from the failure itself, which is why it's usually the tester's call: you saw the evidence, you know what breaks. It goes on the report at filing time.

Priority: How Soon, for the Business

Priority measures urgency: fix now, fix this sprint, fix someday. And it's a business judgment — what does this bug cost us per day, who's affected, what does the release calendar look like, what would customers see? That's why priority is usually product's call — Petra's, at Fernway — informed by your severity and evidence. The hospital ER runs on exactly this split: severity is the diagnosis (how sick is this patient), priority is the triage order (who gets seen first) — and a famous patient with a scratch may be seen quickly while the diagnosis stays "scratch."

The Four Corners

Severity and priority usually travel together — but the corners where they split are where the understanding lives, and interviews aim exactly there:

The Lifecycle: a Bug's Journey

From filing to closure, a bug moves through states — and yes, this is Chapter 4's state diagram applied to your own artifact; forbidden transitions included. The main road: new (filed, awaiting triage) → triaged (severity checked, priority assigned, owner picked) → in progress (a developer is on it) → fixed (the developer believes it's done — note the word believes) → verified (QA re-tested the fix on a build that contains it — Chapter 3's re-testing, now a lifecycle gate) → closed. The loop road: reopened — verification failed, or the bug returned; it happens, it's normal, the state exists so nobody pretends otherwise.

And the exits that don't pass through "fixed": duplicate (already reported — closed with a link to the original), cannot reproduce (the steps don't produce the failure for anyone else — sometimes an environment difference, sometimes a report problem, occasionally a genuinely vanished bug), and won't fix (real, understood, and deliberately not worth fixing). Each exit is legitimate when it's a decision — and each is a failure mode when it's a dodge, which is why the next topic's tracker hygiene matters.

The Gate QA Owns

Look at the lifecycle again and notice which transition belongs to you: fixed → verified. Nobody closes a bug except the person who can re-run the failing scenario — not the developer who believes it's fixed (belief is not evidence; that's why the state is called "fixed," not "gone"), not a manager tidying the board. This is the one gate QA owns outright, and it's the daily bread of the verification queue: every morning, a handful of "fixed" bugs waiting for your re-test, each one either graduating to verified or bouncing to reopened with your evidence attached. Guard the gate politely and absolutely.

Disagreeing Like a Professional: FW-341's Priority

The split of powers — you propose severity, product decides priority — will eventually produce a decision you disagree with, and how you handle it is a career skill. Live case: FW-341, the zero-guest booking. You file it severity major — a booking with no guests charges real money and corrupts the books. Petra prioritizes it low: she checks the data, and no real traveler has ever booked zero guests; the validation fix ships next sprint with other form work. You disagree — quietly convinced it's a money bug waiting for a bored teenager. The professional move: state your case once, with data ("the API also accepts it, so the UI fix alone won't close the hole — see FW-341's comments"), get the decision on record, and commit to it. Priority is Petra's call; making sure it's an informed call is yours. You'll be right sometimes, wrong sometimes; the record keeps everyone honest either way.