Severity vs Priority in Software Testing: Differences, Matrix and Real Examples
Severity says how much damage a bug does. Priority says how soon to fix it. Learn why they do not always match, see all four combinations with examples, and run triage meetings that end with clear decisions.
- Severity measures a bug’s impact on the system. Priority measures how urgently it should be fixed.
- Testers usually propose severity, while product owners usually decide priority.
- They are independent, so a typo can be urgent and a crash can wait.
- Priority changes with business context, while severity tends to stay stable.
A misspelled company name on the home page and a crash in a rarely used export feature: which do you fix first? Arguments like this are why testing teams separate severity vs priority. One describes the technical damage, and the other describes the business urgency.
Without that distinction, every bug gets labelled “critical”, the labels lose their meaning and developers stop trusting them. This guide gives you clear definitions and examples, along with a simple process for making these decisions. The examples are illustrative, and the exact scales differ between teams and tools.
The short answer
Severity answers: how badly does this bug affect the product? A crash or data loss is severe, while a cosmetic glitch is not.
Priority answers: how soon should we fix it? That depends on customers affected, deadlines, revenue, legal exposure and brand reputation.
Think of a hospital. Severity is how serious the patient’s condition is. Priority is the order in which patients are treated, which also depends on other factors, such as who can wait safely and what resources are free.
Severity vs priority side by side
| Aspect | Severity | Priority |
|---|---|---|
| Question | How bad is the impact? | How soon must it be fixed? |
| Focus | Technical effect on the system | Business need and scheduling |
| Usually set by | Tester or QA engineer | Product owner or project manager |
| Basis | Observed behaviour | Customers, revenue, deadlines, risk |
| Changes over time? | Rarely | Often |
| Decides | How serious the defect is | The order of the fix queue |
Severity levels
Most teams use around four or five levels. Here is a common scale:
| Level | Meaning | Example |
|---|---|---|
| Critical (S1) | System down, data loss or a security breach, with no workaround | Saving an invoice deletes customer records |
| Major (S2) | A key feature is broken, or only a hard workaround exists | Search returns no results for any query |
| Moderate (S3) | A feature partly fails, and a reasonable workaround exists | The date filter fails, but sorting by date works |
| Minor (S4) | Small inconvenience, functionality intact | A tooltip appears in the wrong position |
| Trivial (S5) | Cosmetic only | A slightly misaligned icon |
Priority levels
| Level | Meaning | Typical action |
|---|---|---|
| P1, urgent | Must be fixed now | Drop other work, and consider a hotfix |
| P2, high | Must be fixed before the next release | Schedule in the current sprint |
| P3, medium | Should be fixed soon | Place in an upcoming sprint |
| P4, low | Fix when there is capacity | Keep in the backlog, and review it now and then |
Write down what each level means for your team, ideally with a target response time for each. “P1 means someone starts within an hour” is far more useful than “P1 means very important”.
The four combinations, with examples
The clearest way to understand this is to look at each combination:
| High priority | Low priority | |
|---|---|---|
| High severity | Checkout fails for all customers during a sale | A crash when exporting to a file format that almost nobody uses |
| Low severity | The company name is misspelled on the home page | A typo in an old help article with few readers |
High severity, high priority
Checkout fails for everybody, the business loses money by the minute, and there is no workaround. This is the obvious case: drop everything and fix it.
High severity, low priority
The application crashes when exporting to a legacy format. Technically, that is a serious failure. But if only a tiny share of users ever touch this feature, and a modern format works fine, it can wait for a scheduled release.
Low severity, high priority
The company name is misspelled on the home page. Nothing is broken, and no data is at risk. Yet every visitor sees it, it damages trust, and if a major launch is due tomorrow, it needs fixing today.
Low severity, low priority
A small typo in a rarely visited help article. Fix it when convenient. If your backlog is full of these, consider batching them into one clean-up task.
One bug, two different priorities
The same defect can deserve different priorities depending on context. Suppose an order confirmation email goes out with the wrong logo.
| Context | Severity | Priority |
|---|---|---|
| Small internal tool | Minor | P4 |
| Public brand just rebranded, with an announcement this week | Minor | P1 or P2 |
Severity did not change, because the impact on the system is the same. But the business situation did. Time can change things too. A bug that is P3 today may become P1 the week before a major client’s go-live.
Tip: Some changes in context do affect severity. Wrong tax calculations might seem moderate until you learn that they apply to all invoices, so check how widely a bug reaches before you settle on a level.
Who decides severity and priority?
- Testers usually propose severity, since they have seen the behaviour and understand the impact on the system.
- Product owners or managers usually decide priority, as they weigh customers, revenue and the roadmap.
- Developers add information about the cause, the risk of a fix and how long it will take.
- Support teams bring evidence of how many customers are affected and how badly.
Sources and teams vary on these responsibilities, and in a small startup one person may do all of it. What matters is that everybody knows who makes the final call, so disagreements end with a decision.
How to assess a bug
When you are unsure, work through these questions.
For severity:
- Does it lose or corrupt data, or expose private information?
- Does it stop a main function from working?
- Is there a workaround, and could a normal user find it?
- How much of the feature is affected?
For priority:
- How many users are affected, and which ones?
- Does it cost money, or create legal or compliance risk?
- Is a release, demo or sale coming up?
- How visible is it, and could it damage your reputation?
- Does it block other work, such as testing?
Running bug triage
Triage is the regular meeting where a team reviews new bugs and decides what happens next. A simple format works well:
- Prepare. The tester makes sure that each new bug has clear steps, evidence and proposed severity.
- Confirm. Check that it can be reproduced and is not a duplicate.
- Decide. Agree on severity, set a priority and assign an owner.
- Close the loop. Reject, defer or schedule each bug, and record the reason.
Keep it short and frequent. During the final days before a release, a daily 15-minute triage is common. Severity and priority also feed your release decision, so agree on rules up front, such as “no open S1 or S2 bugs at release”, as part of your exit criteria.
Severity and priority in a bug report
A short, clear entry helps everyone make a good decision:
Title: Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build: 2.14.0, production
Reach: All customers using a coupon (around 30% of orders)
Steps: 1. Add an item 2. Apply SAVE10 3. Click Pay
Result: Error 500 and no order is created
Expected: Order is created with the discount appliedThose figures are examples. In a real report, use measured numbers from your logs, and explain your reasoning. Learn more in our guide on how to write a bug report. It also helps to know what the error codes mean, so keep our HTTP status codes cheat sheet handy.
Common mistakes
- Treating them as the same field. If the two always match, you are losing useful information.
- Inflating severity to get attention. Once everything is critical, nothing is.
- Letting testers set priority alone. They rarely have the full business picture.
- Never reviewing the backlog. Priorities go stale, so re-check old bugs regularly.
- No written definitions. Without them, people apply labels differently, and you end up debating words.
- Ignoring low-severity pile-ups. Fifty minor issues can make a product feel broken, even if none is serious alone.
Final thoughts
Keep the two questions separate: how bad is it, and how soon must it be fixed? Agree on written definitions for each level, and make it clear who decides. As a next step, take the ten oldest bugs in your tracker and re-rate them using the questions above. You will probably find a few that should move, and a few that should be closed.
Frequently asked questions
What is the difference between severity and priority?
Severity is how much a defect harms the system. Priority is how urgently it should be fixed. One is about technical impact, and the other is about business urgency.
Can a bug have low severity and high priority?
Yes. A misspelled company name on the home page breaks nothing, but it is highly visible, so a team may want it fixed immediately.
Can a bug have high severity and low priority?
Yes. A crash in a rarely used legacy feature is technically serious, but with few affected users and a good alternative, it can wait.
Who sets severity and priority?
Testers usually propose severity, and product owners or managers usually decide priority. Many teams finalize both together during a bug triage meeting.
Which should be fixed first, high severity or high priority?
Fix in priority order, since priority is what decides the queue. Severity is an important input, though, so serious bugs usually receive high priority.
Keep learning
Need help with testing, WordPress or SEO?
We help teams ship better software and grow their sites. Tell us what you are working on and we will suggest a clear next step.