Bug Severity vs Priority Explained: A Triage Checklist That Ends the Argument
Severity vs priority explained through a 7-question triage checklist, the four quadrants, real disagreements and how to resolve them, plus a copy-ready triage note.
2026-07-17 · By SoftwareTestPilot
Most testers can recite the textbook line: severity is impact, priority is urgency. Then a triage meeting starts, a product manager says "this is a P1", a developer says "it is barely a bug", and the textbook line stops helping. This guide is for that moment. It gives you a short checklist you can run on any defect, shows the four combinations you will meet in real projects, and explains how to handle the disagreements that make triage drag on.
If you want the scoring method and Jira setup, read our companion guide on severity vs priority in testing. If you want a long list of sorted examples, see 30 real bug examples by severity and priority. This article is about the conversation around the two fields.
The two fields in one paragraph each
Severity describes what the defect does to the product when it happens. It is a technical judgement about damage: lost data, blocked workflows, wrong results, ugly screens. A tester can usually set it alone, from the evidence in the bug report.
Priority describes when the team will fix it, compared with everything else in the queue. It is a business decision that weighs severity against how many people are affected, deadlines, contracts, reputation and the cost of the fix. The product owner normally owns it, with input from QA and engineering.
The two are related but not tied together. Severity rarely changes once the facts are known. Priority can change every week as releases, customers and deadlines move. The ISTQB Foundation syllabus uses the same split, which is why interviewers love asking about it.
The 7-question triage checklist
Run these questions in order. The first four set severity. The last three set priority. Writing the answers in the ticket makes the final values easy to defend.
- What breaks? Name the function, not the screen. "Saving an invoice" is clearer than "the invoice page".
- What is lost? Money, data, access, accuracy, time, or only appearance. Data loss and money loss push straight to Critical.
- Is there a workaround? A safe, reasonable workaround usually drops severity by one level. "Refresh the page" counts; "call support" does not.
- How reliably does it happen? Always, sometimes, or once. A rare crash keeps its severity, but note the reproduction rate so priority can account for it.
- Who hits it, and how many? All users, one plan, one browser, one region, internal staff only. Use analytics or logs if you have them instead of guessing.
- What deadline or promise is involved? A release date, a demo, a legal requirement, a customer contract, an app store review.
- What does the fix cost? A one-line fix for a medium bug is often worth doing now. A risky rewrite for a low bug can wait.
Questions 1 to 4 belong to the tester. Questions 5 to 7 belong to the room. When a debate starts, ask which question the disagreement is really about. Nine times out of ten it is question 5 or 6, which means it is a priority argument, not a severity one.
Severity levels with plain tests
| Level | Plain test | Typical example |
|---|---|---|
| Critical | Data or money is lost, security is exposed, or a core workflow is impossible with no workaround | Orders charge the card but are never created |
| High | A major feature is broken or gives wrong results, and the workaround is painful | Search ignores the date filter on the reports page |
| Medium | A feature works but badly, or a reasonable workaround exists | Export works only after a second click |
| Low | Appearance, wording, or minor inconvenience; nothing is wrong functionally | Button label is cut off on narrow screens |
Priority is usually written P1 to P4 (some teams use P0 for "stop everything"). Agree on what each means in time, for example P1 = this release, P2 = next sprint, P3 = planned, P4 = only if convenient. Without a time meaning, priority labels drift into opinions.
The four quadrants you will actually meet
High severity, high priority
The easy case. Checkout fails for every user on the latest app build. Everyone agrees, and the only question is who fixes it first. Your job as a tester is to make the report complete fast: build number, steps, logs, and whether a rollback would fix it.
High severity, low priority
The case that upsets testers most. The app crashes when a user uploads a 2 GB file on an old Android version, and analytics shows a handful of such attempts a month. The damage is real, so severity stays High or Critical. But the business can reasonably schedule it later. Do not lower severity to make the ticket look consistent; leave both values honest and write the reason for the low priority in the ticket.
Low severity, high priority
The case that confuses new testers. A misspelled company name on the home page, a wrong price label in a campaign banner, an outdated legal sentence. Nothing breaks, so severity is Low. But it is visible, embarrassing or legally sensitive, so it gets fixed today. This is exactly why the two fields exist separately.
Low severity, low priority
The backlog. Slightly uneven spacing, a tooltip with clumsy wording. Keep these tickets short, tag them for a polish sprint, and close them in bulk when the area is redesigned. A backlog full of stale cosmetic tickets hides the bugs that matter.
Five disagreements and how to settle them
- "It is only a UI bug, so it is Low." Check question 2. If the UI hides the only button that saves work, the user loses data, which is Critical. Severity follows the damage, not the layer of code.
- "It is rare, so lower the severity." Rarity belongs to priority. Keep the severity and add the reproduction rate, such as "3 of 20 attempts".
- "The customer is shouting, so make it Critical." Customer pressure is a priority signal. Raise priority, keep severity honest, and link the support ticket so the reason is visible.
- "Every bug from QA is marked High." If this is said about your team, it is probably true. Run the checklist for a week and include the answer to question 3 (workaround) in every report. Inflated severity makes real Criticals easier to ignore.
- "Nobody set priority." Testers often leave priority blank, waiting for the product owner. Propose a value with a one-line reason instead. A suggestion speeds up triage; an empty field slows it down.
A copy-ready triage note
Paste this block at the bottom of a bug report before triage. It turns the checklist into something a busy product owner can read in thirty seconds.
Triage note
What breaks: Saving a draft invoice
What is lost: Unsaved line items (user data)
Workaround: None found
Reproduction: Always, Chrome and Firefox, build 4.12.0
Who is affected: All users on the Business plan (about 1 in 3 accounts)
Deadline: Month-end billing run in 6 days
Fix estimate: Developer guess: small, validation change
Proposed severity: Critical (data loss, no workaround)
Proposed priority: P1 (affects billing run this month)The note also protects you later. If the priority is lowered, the reasoning is on record, and nobody can say QA did not explain the risk. Our Jira bug report template includes matching fields if you want the whole report in one format.
Worked example: one bug, three meetings
A tester finds that changing the account email address logs the user out of every device and does not send a confirmation message. The user can log back in with the new email, but if they mistyped it, they are locked out.
Meeting 1 (sprint triage). Severity: High. A typo can lock a user out, which is loss of access, and the only workaround is contacting support. Priority: P2. Few users change their email in a given week, and the release is focused on billing.
Meeting 2 (a week later). Support reports four lockouts in two days after a marketing email asked users to update their details. Severity does not change; the damage is the same. Priority moves to P1 because the number of affected users has jumped and support costs are rising.
Meeting 3 (after the fix). The fix adds confirmation before the change takes effect. The tester verifies it, adds a regression test for the email-change flow, and closes the ticket with a short note on why priority changed. That history is useful the next time a similar bug appears.
The pattern to notice: severity stayed stable because the facts stayed stable. Priority moved because the business context moved. If your team's severity values change as often as priority, the checklist is not being used.
Using the two fields for reporting
Once both fields are set honestly, they become useful data. Three simple reports help most teams:
- Open Critical and High by age. Anything older than one sprint deserves a conversation.
- High severity, low priority list. Review it monthly. These are the risks the business has chosen to accept, and someone should confirm that choice is still right.
- Escaped defects by severity. Bugs found in production, grouped by severity, tell you where testing coverage is thin. Pair this with your defect life cycle states to see where bugs wait longest.
Avoid ranking testers by how many Critical bugs they log. It rewards inflation and punishes testers who work on stable areas.
How to answer this in an interview
Interviewers ask "what is the difference between severity and priority" to see whether you have done real triage. A strong answer takes under a minute:
- Give the two definitions in one sentence each.
- Give one low-severity, high-priority example and one high-severity, low-priority example.
- Say who owns each field in your team.
- Mention one time priority changed while severity stayed the same, and why.
That fourth point separates people who have read about triage from people who have sat in it. For more practice questions on this topic, see our software testing MCQ quiz or ask other testers in the QA Community.