Severity vs Priority Differences
Quick Answer
- Severity is how badly a defect affects the application — its technical impact.
- Priority is how soon the defect should be fixed — its business urgency.
Severity = impact. Priority = urgency.
They're set independently, usually by different people, so a defect can be any combination of the two.
Comparison at a Glance
| Aspect | Severity | Priority |
|---|---|---|
| Question it answers | How much does this defect break the application? | How soon must it be fixed? |
| Based on | Functional and technical impact | Business value, customer impact, deadlines |
| Typical levels | Blocker, Critical, Major, Minor, sometimes Trivial | Urgent/Highest, High, Medium, Low |
| Usually set by | The tester who reports it | Product owner, project manager or triage team |
| Changes over time? | Rarely — the impact usually stays the same | Often — with release dates and business needs |
Severity Levels
| Level | Meaning | Example |
|---|---|---|
| Blocker | Testing or use can't continue at all | The application won't start; login fails for everyone |
| Critical | A core function is broken, with no workaround | Payments fail; orders aren't saved |
| Major | A significant function is wrong, but a workaround exists | Search filters ignore the price range; sorting is wrong |
| Minor | Small functional issue with little impact | An error message is unclear; a field doesn't trim spaces |
| Trivial | Cosmetic only | Misaligned icon; typo in a tooltip |
Level names vary between companies and tools. The important thing is to use your team's definitions consistently.
Priority Levels
- Urgent / Highest — Fix immediately, possibly with a hotfix; the business is losing money or customer trust now.
- High — Fix in the current sprint or before the next release.
- Medium — Fix during the normal course of work, preferably before the release.
- Low — Fix when there is capacity; it can move to a later release.
In Jira, the default priority field uses Highest, High, Medium, Low and Lowest.
More: Defect Management in Jira.
All Four Combinations With Examples
Interviewers often ask about all four combinations because they want to check whether you understand that severity and priority are independent.
High Severity + High Priority
Example: Customers complete payment on an e-commerce site, but the application crashes before the order is created.
Core business functionality is broken, making the defect highly severe. At the same time, the company is losing revenue immediately, making it highly urgent.
Other examples include:
- Checkout fails completely.
- Cart items disappear during checkout.
- Users cannot log in.
- Orders cannot be created or saved.
High Severity + Low Priority
Example: The application crashes when a user exports a yearly report in an old file format that only a handful of internal users still use.
A crash can have high technical severity, but if very few users are affected and a reasonable workaround exists, the business may decide that fixing it can wait for a later release.
Another example could be a crash that occurs only on a very old, officially unsupported browser version.
Low Severity + High Priority
Example: The company name is misspelled in the logo on the home page, or the wrong price appears in a banner for tomorrow's major sale.
Nothing is functionally broken, so the technical severity is low. However, every visitor may see the issue, and it can affect brand trust, marketing accuracy or compliance.
Therefore, the business may assign it a high priority.
Low Severity + Low Priority
Example: A spelling mistake or slight alignment issue appears on a rarely visited "Terms of Use" page.
The functional impact is minimal and there is little immediate business urgency, so the issue can normally be fixed when convenient.
Who Decides Each?
- Severity is usually set by the tester who finds the defect, based on its technical and functional impact.
- Priority is generally decided by the product owner, project manager or business, often during defect triage with the QA lead and development lead.
Developers can provide valuable input about implementation effort, technical risk and dependencies, but priority is generally a business decision.
Many teams allow the tester to suggest a priority when logging the bug. The product owner or triage team can then confirm or change it.
How to Set Severity: Questions to Ask
When deciding severity, ask:
- Does the defect block testing or normal use of the application?
- Is a core business flow broken, such as login, payment, ordering or data saving?
- Is there a workaround?
- Does the defect cause data loss?
- Does it produce incorrect calculations or results?
- Does it create a security risk?
- Is the problem purely cosmetic?
These questions help distinguish technical impact from business urgency.
Factors That Drive Priority
Priority is influenced by factors such as:
- How many users are affected.
- Which users are affected, such as paying customers or internal staff.
- Revenue impact.
- Legal or compliance requirements.
- Brand or customer-experience impact.
- Release deadlines.
- Upcoming events such as sales, demos or audits.
- Whether a workaround exists.
- How practical and acceptable the workaround is.
A defect affecting a small number of users can sometimes receive high priority if those users are strategically important or if the issue is connected to an upcoming business event.
Common Mistakes
Setting Everything to Critical or High
If every defect is marked Critical or High, nothing stands out.
Severity and priority should reflect the actual impact and urgency rather than making every issue appear urgent.
Letting Priority Change the Severity
A defect's severity represents its impact.
For example, a crash does not become technically less severe simply because the business decides to fix it later.
Leaving Priority to the Developer Alone
Developers should provide technical input, but urgency is generally determined by business needs, customer impact and release requirements.
Not Explaining the Impact
A bug report should clearly explain why the defect matters.
Instead of writing:
"Payment button is not working."
Provide useful context:
"Payment submission fails for all customers using credit cards, preventing order completion and blocking revenue transactions."
Clear impact information helps the triage team make decisions quickly.
The Interview Answer
"Severity is the technical impact of a defect on the application; priority is how urgently the business needs it fixed. Testers usually set severity, and the product owner or triage team decides priority. They're independent — for example, a crash in a rarely used legacy report is high severity but low priority, while a misspelled company name on the home page is low severity but high priority."
Practise answering questions like this under time pressure in the Selenium Interview Simulator.
From Real Projects
I've used Jira for defect tracking on every project I worked on — Apkope, Canolog and Testsigma — together with TestRail for tracking test execution. My work included preparing bug reports, following defects through the bug life cycle and retesting fixes. A clear, reproducible report — exact steps, expected versus actual result and evidence — gets a defect resolved faster than anything else. Severity describes the impact; priority is a business decision about when to fix it.
Frequently Asked Questions
What is the difference between severity and priority?
Severity measures how much a defect affects the application, while priority measures how quickly it should be fixed based on business needs.
Give an example of high severity and low priority.
A crash when exporting a report in an old format that very few users need can be considered high severity but low priority because the affected functionality has limited business usage.
Give an example of low severity and high priority.
A company name misspelled in the home-page logo is a good example. Nothing is functionally broken, but every visitor may see the mistake, making the issue commercially important.
Who decides severity and priority?
Testers usually set severity based on technical and functional impact.
The product owner, project manager or triage team generally decides priority based on business urgency and customer impact.
Can priority change after a bug is logged?
Yes.
Priority can change when business requirements, customer impact, release plans or deadlines change.
Severity generally remains stable unless new information reveals that the actual impact is different from what was originally understood.
What are the severity levels?
Common severity levels are:
- Blocker
- Critical
- Major
- Minor
- Trivial
However, severity names and definitions vary between organisations and testing tools.
Related
- Defect Bug Management: Life Cycle, Severity, Priority & Triage
- The Complete Jira for Testers Guide
- The Complete Manual Testing Tutorial
- Top 30 Manual Testing Interview Questions
