Severity vs Priority in Software Testing: Differences, Matrix & Examples

Last updated: July 11, 2026 · 7 min read

Severity vs priority is one of the most-asked QA interview questions — and one of the most-confused concepts on real teams. This guide gives you sharp definitions, a matrix, and worked examples.

Severity — the technical impact of a defect on the system. Objective. Set by QA.

Priority — how urgently the defect must be fixed relative to other work. Business-driven. Set by PM / Product Owner.

The mismatched quadrants are the interesting ones — high sev / low pri and low sev / high pri — because they show that severity alone can't drive scheduling.

1. High severity, high priority: checkout API returns 500 for 30% of requests.
2. High severity, low priority: data-export crashes for accounts > 10M rows (2 customers affected, workaround: chunked export).
3. Low severity, high priority: misspelled CEO name on the About page before a press release.
4. Low severity, low priority: footer copyright still says 2024.

• Severity — QA engineer at defect logging. It's technical and objective.
• Priority — PM / Product Owner at triage. It's business-driven and negotiable.
• Both can be adjusted at the daily bug triage meeting when new context arrives.

"Severity is the technical damage the defect causes to the system — I set it as QA. Priority is how urgently business wants it fixed — the PM sets it. They're independent: a small typo on the homepage before a launch is low severity but high priority; a crash in a rarely-used admin export is high severity but low priority."

• Defect Life Cycle
• Software Testing Interview Questions
• Software Testing MCQ Quiz