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

Severity and priority are the two fields every bug report carries, and the two most teams fill in carelessly. Severity describes how much damage a defect does. Priority describes how soon the team will fix it. This guide explains the difference, gives you a scoring method you can apply in under a minute, shows how to set both fields in Jira, and walks through a real triage meeting so you can see the two values pulling in different directions.

If you only need quick examples, our companion piece 30 real bug examples sorted by severity and priority is a faster read. This article is about the reasoning behind each value.

• Severity is the technical impact of the defect on the product: what breaks, for whom, and whether there is a workaround. It is decided mainly by the tester who found and reproduced the bug.
• Priority is the order in which the defect will be fixed compared with all other work. It is decided by the product owner or triage group, because it depends on release dates, customers and business risk.

The short version for interviews: severity is about the product, priority is about the schedule. They often line up, but they are separate decisions made by different people with different information.

Most teams use four levels for each field. The names vary by tool, but the meaning is consistent.

Keep the definitions written down in your team wiki. Most severity arguments come from people using different mental definitions of “major”.

Ask three questions about the reproduced bug and add the scores. This removes most of the guesswork.

Score 5-6: S1. Score 3-4: S2. Score 2: S3. Score 0-1: S4. Treat any data loss or security exposure as S1 regardless of the total, because those cannot be undone.

The method is deliberately simple. Its value is consistency: two testers looking at the same bug should land on the same level, and a developer can see exactly why.

Priority starts from severity, then moves up or down based on things a tester often cannot see:

• Release timing. A minor bug on a page that goes live tomorrow can jump to P1.
• Who is affected. One enterprise customer under contract can outweigh thousands of free users.
• Visibility. Anything on the home page, in a launch email or in an app store screenshot gets attention.
• Legal or compliance exposure. Wrong tax, privacy or accessibility behaviour is often raised even when the technical impact is small.
• Cost of fixing. A severe bug in code that is about to be replaced may be left alone on purpose.

This is why testers should suggest a priority but should not insist on it. Write down the facts that support your suggestion and let the owner decide.

The two mismatched boxes are what interviewers ask about. Prepare one example of each from your own work, with the reason the priority differed from the severity.

A team released a new booking flow the night before. Four bugs arrive by 9 a.m.

1. Double charge when the user presses Pay twice. Money is taken incorrectly, no workaround for the user. Score 6, S1. Priority P1: payments are switched to a single-click guard within the hour and a hotfix follows.
2. Date picker shows the wrong month for users in some time zones. Booking still works if the user notices. Score 3, S2. Priority P2: fixed this sprint, with a short note in the help centre.
3. Confirmation email uses the old logo. No functional effect. Score 1, S4. Priority P2, because marketing is sending a campaign on Friday that links to the same template.
4. Admin export times out above 50,000 rows. Only internal staff affected; they can export by month. Score 2, S3. Priority P3.

Notice bug 3: lowest severity, but fixed before bug 4. Nobody changed the severity to justify that. The severity stayed honest and the priority carried the business reason. Keeping the two fields independent is what makes the history useful when you look back months later.

Jira has a built-in Priority field but no severity field by default. Most teams add a custom single-select field called Severity. Once both exist, you can build triage views with JQL:

project = SHOP AND issuetype = Bug AND status != Done
  AND (priority = Highest OR Severity = "S1 Critical")
ORDER BY priority DESC, Severity ASC, created ASC

Two more filters worth saving:

-- Severe bugs that were never prioritised
issuetype = Bug AND Severity in ("S1 Critical", "S2 Major") AND priority in (Low, Lowest)

-- Bugs missing a severity value
issuetype = Bug AND Severity is EMPTY AND created >= -14d

The first filter is a useful weekly check: a high-severity bug with low priority is sometimes correct, but each one should have a written reason. See the Atlassian JQL documentation for the full syntax.

• Raising severity to get attention. If every bug is critical, none are. Use the scoring method and argue for priority instead.
• Letting priority overwrite severity. When a manager says “make it low”, they usually mean priority. Change that field and leave severity alone.
• Leaving out the workaround. The workaround is often the deciding factor between S2 and S3. Always write it in the report, or write “none found”.
• Never revisiting priority. Priority should change as dates and customers change. Severity should change only when new facts about impact appear.
• Using more than five levels. Extra levels create arguments about boundaries without improving decisions.

For the full report structure that carries these fields, read how to write a bug report developers act on, and for what happens after triage see the defect life cycle.

“Severity is the technical impact of the bug on the product, which I assess as the tester using what breaks, how many users it affects and whether there is a workaround. Priority is when it gets fixed, which the product owner decides based on release timing and business risk. They are independent: on one release a wrong logo in a launch email was minor severity but fixed first, while a crash in an internal export was more severe but scheduled later because staff had a workaround.”

Follow-up questions to expect: who has the final say on priority (the product owner), can severity change (only when new impact information appears), and how you handle a disagreement (bring evidence, not volume). Practise more of these in our software testing interview questions and discuss real cases with other testers in the QA Community.

• Bug severity vs priority explained with a triage checklist
• 30 real bug examples by severity and priority
• Software testing MCQ quiz

Related reading: Smoke vs Sanity Testing: 7 Clear Differences with Examples.