QA StepsJoin the waitlist

Severity vs priority, with examples

Severity is how much harm a defect does to the product and its users. Priority is how soon the team should fix it compared with other work. The two are set independently: the tester sets severity from the harm they saw, and the product owner or a manager sets or changes priority from business plans. The order of work follows priority. A typo in a button every visitor sees can be minor in severity and high in priority, and a rarely used function that fails completely can be major in severity and low in priority.

2 scales
set independently, by different people
4 combinations
on one practice shop
8 defects
graded, each with its reason

How to set both for a bug, step by step

  1. Step 1

    Describe the harm in one sentence

    What can the user not do, what is lost, and is there a workaround? Write the sentence before you pick a level: the level follows from the sentence, not the other way round.

  2. Step 2

    Pick the severity level

    Match the sentence to your team's scale. Judge the harm in the product, not how hard the bug was to find or how annoyed you are.

  3. Step 3

    Count who meets it

    Every visitor, every buyer at checkout, or a few people a year? How many people meet a defect does not change its severity, but it is the first input to priority.

  4. Step 4

    Ask what the business has planned

    A release date, a sale, a demo for a partner or a legal deadline can raise priority without any change in harm. If you do not know the plans, ask.

  5. Step 5

    Propose a priority with its reason

    Write the reason next to it: "High: every product page shows it." A reason lets the product owner agree or change it in a minute.

  6. Step 6

    Accept the decision, update on new facts

    The priority set at triage stands. If you learn more about the harm, for example that data is lost, raise the severity and say why in a comment.

What severity and priority mean

Severity describes the defect: how badly it damages what the product does for its users. A checkout that takes the money and loses the order is severe; a misaligned icon is not. Severity belongs to the defect itself, so it rarely changes unless you learn something new about the harm.

Priority describes the work: in which order the team fixes defects, given everything else it has to do. It depends on things outside the defect: how many people see it, what the business has planned, what a fix costs and what waiting costs. Priority can change while the defect stays exactly the same, for example when a release date comes closer.

The two fields answer different questions for different readers. Severity tells the team what is at stake. Priority tells a developer what to pick up next.

Who sets severity and who sets priority

The tester sets severity, because the tester saw the harm and can describe it. The tester usually proposes a priority too, and the product owner or a manager confirms or changes it, because priority depends on business plans a tester may not know. A changed priority is not a verdict on your report.

When many defects are open, teams hold bug triage: a meeting where the product owner, developers and testers go through the open defects and decide which get fixed and in what order. Not every defect is fixed. Every defect is written down.

The scales

There is no single standard scale: each team and each tool sets its own. A practical severity scale has four levels, and Jira's default priority list has five. The course behind this guide uses these two, and they map onto most other tools.

Tools differ in the details. Qase, a test management tool, has six severity levels (Trivial, Minor, Normal, Major, Critical, Blocker) and three priorities (Low, Medium, High). Many teams keep only priority in their tracker, and interviewers still ask about both. Learn your team's scale on the first day and use its words.

Two scales
Severity: how much harm
  Critical  a key flow cannot be used at all, no workaround
            (the customer cannot pay, data is lost)
  Major     a key function works wrong for many users;
            a workaround is hard or missing
  Medium    a function works wrong, but a workaround exists
            or few users meet it
  Minor     cosmetic or rarely noticed; the task is not affected

Priority: how soon (Jira's default list)
  Highest   this problem will block progress
  High      serious problem that could block progress
  Medium    has the potential to affect progress
  Low       minor problem or easily worked around
  Lowest    trivial problem with little or no impact on progress

All four combinations on one shop

Most explanations take each combination from a different product: a misspelled logo on one site, a crash in a banking app on another. Four defects of one shop make the difference easier to see, because the product and its users stay the same and only the harm and the timing change.

Shelf is the practice shop the courses use: kettles, bikes, books, lamps and backpacks, with test cards instead of real payments. The four defects below are invented for this guide; the labels and messages are the shop's real ones.

  • High severity, high priority

    Paying for an order with the test card 4242 4242 4242 4242 shows "Payment received. Thank you for testing with Shelf.", but the order stays Awaiting payment. Customers pay and get nothing. Critical, Highest: fix it before anything else.

  • Low severity, high priority

    The "Add to cart" button on every product page reads "Add to crat". Every visitor can still buy. Minor, High: nothing breaks, but every visitor sees it, and the fix is one word.

  • High severity, low priority

    "Reset my data" on the Account page fails with an error, and the cart and orders stay. The function is broken and there is no workaround, but almost nobody uses it. Major, Low: it waits behind work that more customers notice.

  • Low severity, low priority

    With the window 1280 pixels wide, the last word of the catalog's "No products match these filters." message wraps onto a line of its own. Minor, Lowest: cosmetic, rarely seen, and nobody is waiting for it.

Four more, in between

Real triage rarely lands in a clean corner. Here are four more defects of the same shop, also invented, with the levels the course gives them. Read the defect, decide both levels yourself, and only then read the answer.

  • "One more of" in the cart stops at 9

    Quantity 10 can still be typed into the number field. Medium, Medium: a workaround exists, and few buyers want 10 of one product.

  • Canada is missing from the checkout country list

    The spec lists it. Customers in Canada cannot finish an order at all. Major, High: a whole group of customers is locked out of a key flow.

  • The discount reads "USD 25.0"

    Coupon SAVE25 is applied and the total is right, but the summary shows one decimal place. Minor, Medium: the money is correct, and the shop looks careless at the moment the customer pays.

  • An 80-character search shows an empty white page

    Medium, Low: the visitor can go back and search with fewer words, and searches that long are rare.

What moves each one

When you are unsure, go through these questions. The first group sets severity, the second sets priority. A defect can rank high on one list and low on the other, and that is why there are two fields.

  • Severity: what is lost

    Money, data, an order, or only a few seconds. Lost money or data sits at the top of any scale.

  • Severity: is there a workaround

    If the user can reach the goal another way, the level usually drops by one.

  • Severity: which flow

    Sign-in, cart and payment are key flows in a shop; a rarely visited settings page is not.

  • Priority: who sees it, how often

    Every visitor, every buyer, or a few people a year.

  • Priority: what is coming

    A release, a sale, a demo for a partner, a legal deadline.

  • Priority: what waiting costs

    A defect that blocks further testing, or that customers see in public, rarely waits.

  • Neither: how hard it was to find

    A bug you hunted for an hour is not more severe for it. Neither is one that annoys you.

How to answer in an interview

"What is the difference between severity and priority?" comes up in almost every first interview for a testing job, usually followed by "Give an example of high severity and low priority." Five sentences answer both: the two definitions, who sets each, one example of each unusual pair and the rule for the order of work.

A short answer
Severity is how much harm a defect does; priority is how soon the team fixes it.
The tester sets severity; the product owner confirms or changes the priority.
High priority, low severity: a typo in the Add to cart button on every product page.
High severity, low priority: a rarely used function, such as resetting account data,
fails completely.
The order of work follows priority, not severity.

Common mistakes

These come up in first bug reports and in interviews. Each one makes the two fields carry less information than they could.

  • "Severity and priority are the same scale"

    They are two independent fields. If one always copies the other, the team is filling in one field twice.

  • "Critical means fix first"

    Usually a Critical defect is also urgent, but priority decides the order. A Critical defect in a feature that is not released yet can wait behind a High one that customers meet today.

  • "The tester's priority is final"

    The tester proposes; the product owner decides. Write your reason so the decision is quick.

  • Every bug is Critical

    When everything is Critical, the scale stops sorting anything, and readers stop trusting it.

  • A level with no reason

    "Major" alone starts a discussion. "Major: customers in Canada cannot order" ends it.

Where to learn this

Questions and answers

What is the difference between severity and priority?

Severity is how much harm a defect does to the product and its users. Priority is how soon it should be fixed compared with other work. They are set independently, and the order of work follows priority.

Can a bug have high severity and low priority?

Yes. A function that fails completely is high in severity, and if almost nobody uses it, the team can fix it later. Example: resetting account data fails with an error, but few users ever reset their data.

Can a bug have low severity and high priority?

Yes. A typo in a button label that every visitor sees harms nothing, but it is visible to everyone and cheap to fix, so it goes near the top of the list.

Who decides the priority of a bug?

The tester usually proposes it and the product owner or a manager confirms or changes it, often at bug triage. Severity is the tester's call, because the tester saw the harm.

What is a blocker?

A defect that stops work: users cannot finish a key flow, or testers cannot go on testing. Some tools have Blocker as the top severity level, Qase among them. Jira's default priority list describes Highest as a problem that will block progress.

Can severity or priority change after the bug is filed?

Priority often changes, because plans change. Severity changes only when you learn something new about the harm; add a comment that says what you found.

More guides

See the first course

The full outline of every course is available: you can see each lesson before you start.

All courses