Severity vs priority in defects, with examples
Severity is how badly a defect breaks the product. Priority is how soon the team should fix it. They are set by different people for different reasons.
By Quality AboveAll · June 25, 2026 · 5 min read
Severity measures technical impact and priority measures business urgency, so a defect can be high in one and low in the other.
Two different questions
Severity asks how much damage the defect does. A crash is high severity. A wrong font colour is low severity. Testers usually set it, because it is about the product itself.
Priority asks how fast it must be fixed. That depends on release dates, customers, and money. Product owners usually set it, because it is about the business.
- Severity: technical impact of the fault.
- Priority: urgency of the fix in the schedule.
A worked example: four real bugs
The clearest way to learn this is to place four defects on the grid:
- High severity, high priority: checkout crashes on payment. It breaks the product and blocks revenue, so fix now.
- High severity, low priority: the app crashes on an old browser used by almost nobody. Serious fault, but it can wait.
- Low severity, high priority: the company logo is misspelled on the home page. Tiny fault, but embarrassing, so fix today.
- Low severity, low priority: a tooltip has a minor typo on a settings page. Fix whenever.
The logo case surprises people. A cosmetic bug can still be top priority when it touches brand or trust.
Severity is what the bug does to the software. Priority is what the bug does to the business.
Why the split prevents fights
When teams use one label for both, triage turns into an argument. A tester marks a crash critical, a manager disagrees because no customer hit it yet, and the ticket stalls.
Splitting the two ends that. The tester owns severity with evidence. The owner owns priority with context. Both facts sit on the ticket, and the queue orders itself. This is standard in mature regression testing and disciplined manual testing, and it maps to the defect handling described by ISTQB.
The honest caveat
Labels are only as good as the judgement behind them. A junior tester under pressure may mark everything high severity, which floods the board and hides the real fire.
That is where an embedded senior tester earns their place. They calibrate the scale, challenge inflated tickets, and keep triage honest. It matters most in financial services and healthcare, where a mislabelled defect carries real cost, and it fits into the flow on our process page.
If your bug queue feels noisy and nobody trusts the labels, that is a fixable problem. Start with a free 30-minute testing audit and we will review how your team scores severity and priority.
Senior-led QA,embedded in your workflow.
Often less than one full-time hire. Book a free 30-minute testing audit and we'll show you exactly where the risk is hiding.