← Back to libraryQuestion 269 of 273
🌀Agile & QABeginner

Severity vs Priority (with Judgment Scenarios)

📌 Definition:

Severity measures the technical impact of a defect on the system (how badly it breaks functionality), while priority measures the business urgency of fixing it (how soon it should be addressed). They are independent axes, and confusing them is a classic QA interview trap.

📖 Detailed Explanation:

Severity is about the defect's effect: a crash or data loss is high severity, a cosmetic misalignment is low severity. Priority is about business urgency: how soon the fix is needed relative to other work. The crucial insight is that the two don't always move together, and all four combinations occur. High severity + high priority: checkout crashes for everyone — fix now. High severity + low priority: an app crashes only on a decade-old browser two users have — bad crash, but not urgent to fix. Low severity + high priority: the company logo is misspelled or wrong on the homepage — trivially 'broken' technically, but embarrassing and urgent to fix before a big launch. Low severity + low priority: minor padding off on an admin page — fix whenever. Severity is usually assigned by QA (technical judgment); priority is usually owned by the PO/business (though QA advises). Being able to give a crisp example of high-severity/low-priority and low-severity/high-priority is exactly what interviewers look for to confirm you truly understand the distinction.

🔑 Key Points:
  • Severity = technical impact (how badly it breaks); Priority = business urgency (how soon to fix)
  • They are independent — all four combinations happen
  • High severity + low priority: severe crash on an ancient browser almost no one uses
  • Low severity + high priority: misspelled brand name/logo on the homepage before a launch
  • QA typically sets severity (technical); the PO/business owns priority (QA advises)
🌍 Real-World Example:

A typo in the company name on the landing page is low severity (nothing is functionally broken) but high priority (it's highly visible and embarrassing right before a product launch), so it's fixed immediately — a textbook low-severity/high-priority defect.

📎 Severity Priority Matrix:
CombinationExampleAction
High severity + High priorityCheckout crashes for all usersFix immediately / block release
High severity + Low priorityCrash only on a 10-year-old browser 2 users haveLog; fix in a later sprint
Low severity + High priorityMisspelled brand name on the homepage pre-launchFix now despite minor technical impact
Low severity + Low priorityMinor padding off on an internal admin screenFix when convenient / backlog
🎯 Scenario-Based Interview Question:

Scenario: In an interview you're asked: 'Give me a real example of a high-severity but low-priority bug, and a low-severity but high-priority bug, and explain who decides each.' How do you answer?

💡 Quick Tip:

Memorize one crisp example of each mismatched case — the misspelled-logo (low sev/high pri) and crash-on-ancient-browser (high sev/low pri) — they're the fastest way to prove you get it.