Free QA resource

Severity vs Priority

The one every interviewer asks — and the one that trips up even experienced testers. Here’s the clean version you can actually remember.

🧠 Severity = how bad the bug is.  Priority = how soon you fix it.

Get the free PDF 📄

Enter your email and the printable cheat sheet is yours instantly — no spam, unsubscribe anytime.

Severity

How seriously the defect affects the application’s functionality. It’s about technical impact — does it crash, corrupt data, block a feature, or is it just cosmetic? The tester sets it, and it doesn’t change based on business mood.

Typical levels

Critical · Major · Minor · Trivial

Priority

How soon the defect should be fixed. It’s about business urgency — release deadlines, customer impact, visibility. Usually the product manager or lead decides it (with QA’s input), and it can shift as plans change.

Typical levels

High (P1) · Medium (P2) · Low (P3)

Side by side

SeverityPriority
What it measuresHow badly the defect affects the productHow soon the defect should be fixed
Driven byTechnical impact / functionalityBusiness need & urgency
Usually set byQA / testerProduct manager / lead (with QA input)
Changes over time?Stays the same — it's the impactCan change with release plans & business
Question it answers“How bad is it?”“When do we fix it?”

The 4 combinations (with real examples)

This is the part interviewers love — give an example for each and you stand out.

Severity: HighPriority: High

Fix immediately

Payment fails on checkout — users can't pay. Breaks a core flow AND hurts revenue right now.

Severity: HighPriority: Low

Bad, but can wait

The app crashes on a rarely-used report screen, or only on a phone model almost no one uses. Big impact, tiny audience.

Severity: LowPriority: High

Small, but fix now

The company name is misspelled on the homepage, or the logo is wrong. Cosmetic — but embarrassing and very visible, so fix it fast.

Severity: LowPriority: Low

Backlog it

A minor text-alignment glitch on a help page that few people visit. Low impact, no urgency.

How to answer it in the interview

Don’t just define the two words — show you understand the difference:

“Severity is how badly the bug impacts the product — it’s technical and set by QA. Priority is how soon we should fix it — it’s a business call. They’re independent: a misspelled company name on the homepage is low severity but high priority, while a crash on a screen almost no one uses can be high severity but low priority.”

Common follow-ups they’ll ask:

  • “Give me an example of high severity but low priority.” (Use the rare-screen crash.)
  • “Who decides each one?” (Severity → QA; Priority → PM/lead, with QA input.)
  • “Can priority change but severity stay the same?” (Yes — severity is the impact; priority follows the release plan.)

Get the free PDF 📄

Enter your email and the printable cheat sheet is yours instantly — no spam, unsubscribe anytime.

Want the full interview prep?

Manual, Selenium, Playwright & Python kits — Q&A, coding, and résumé templates.

🔥 See the SDET Kits