Severity and Priority
Every defect report answers two separate questions. Severity is how bad the impact is: the ISTQB glossary defines it as the degree of impact that a defect has on the development or operation of a component or system. Priority is how soon the defect should be fixed: the level of business importance assigned to it, compared with all the other work the team could do.
In an online pharmacy app, a defect that charges a customer's card without creating the order has high severity: money is taken and nothing is delivered. How soon it is fixed is a separate decision, which depends on how many customers can reach it, whether a workaround exists and when the next release is.
Why it matters
Teams always have more defects than time. Severity and priority let them decide quickly what to fix first and what may ship. When the two are merged into one field, or inflated, a cosmetic issue that a manager noticed gets fixed while a defect that silently corrupts data waits.
For a tester, honest ratings are part of a report's credibility. If your severity follows the evidence, developers and the product owner act on it; if everything you file is Critical, they stop reading the field, and the next real Critical waits with the rest.
Two scales for two questions
Severity describes the defect: what happens when the failure occurs. It changes only when new evidence appears, for example when you find that a crash you reported also empties the cart. Priority describes a decision about the order of work, so it moves with the context: a release date, a campaign, a new workaround, the cost and risk of the fix. The ISTQB Foundation syllabus lists them as separate fields of a defect report.
Scales differ between teams, so this lesson uses the ones from the bug report guide. Priority has four levels, each tied to a time: Highest (fix now; the release waits for it), High (fix in this release), Medium (next sprint) and Low (backlog); some teams write P0 to P3 instead, and some trackers add a fifth level. Severity has five levels, checked from the top until one fits:
- Blocker: a core flow cannot be used and there is no workaround. No customer can place an order.
- Critical: money is lost or wrongly charged, data is lost or corrupted, security is exposed, or a major function fails for most users. A refund is credited twice.
- Major: an important function fails but a workaround exists, or few users are affected. Prescription upload fails from the camera but works from the photo gallery.
- Minor: a small functional or cosmetic problem. Order history is sorted oldest first.
- Trivial: a typo or a negligible visual detail. A full stop is missing in the help text.
Severity
How bad is the impact when the failure occurs?
- Describes:
- The defect and its consequences
- Based on:
- Impact on users, data, money and security, and any workaround
- Who sets it:
- The tester proposes; a developer may correct it with evidence
- Scale in this lesson:
- Blocker · Critical · Major · Minor · Trivial
- Changes when:
- New evidence about the impact appears
Priority
How soon should the team fix it, compared with other work?
- Describes:
- A decision about the order of work
- Based on:
- Impact and frequency, plus dates, visibility and the cost of the fix
- Who sets it:
- The product owner, usually in triage
- Scale in this lesson:
- Highest · High · Medium · Low, or P0 to P3
- Changes when:
- The context changes: a date, a campaign, a workaround
Impact and frequency: the evidence behind both
Impact is what the failure does: to the user (blocked, wrong result, lost work), to data, money, security, legal obligations and trust, and whether a workaround exists. Severity is judged mainly from impact.
Frequency is how often the failure happens: every time, or 3 attempts in 10. Reach goes with it: how far the failure extends, such as all devices or one OS version, the checkout or a yearly report, all customers or one account type. Frequency and reach weigh most on priority, because the same impact on every order is more urgent than on one order a month. Some severity scales use reach as well, like the Major level above, so agree on your team's rule and apply it the same way every time.
- What exactly happens to the user, the data and the money?
- Is there a workaround a normal user would find, and what does it cost them?
- How often does it reproduce, under which conditions, and who can reach it?
- What is the worst outcome you have evidence for, not the worst you can imagine?
Four combinations, with examples
Because the scales answer different questions, every combination occurs. Here high severity means Blocker or Critical and low severity means Minor or Trivial; high priority means Highest or High and low priority means Medium or Low. Major sits between the two severity groups, so it does not form a mixed combination. The mixed combinations need the most care: high severity at low priority needs a written reason, and low severity at high priority is usually about visibility.
Examples from the same pharmacy app, a few days before a release planned for Thursday:
- High severity, high priority: paying with a saved card charges the card but creates no order. Critical, Highest: fix before the release.
- High severity, low priority: switching on the new loyalty-points feature resets existing balances to zero, but a feature flag (a setting that turns a feature on or off without a new release) keeps it switched off until next quarter. Critical, Low for now, with a date to review it before the flag is turned on.
- Low severity, high priority: the home-screen banner for the national-day sale shows last year's date. Nothing is broken, but the campaign starts on Saturday. Minor, High.
- Low severity, low priority: the back arrow on the settings screen sits 2 pixels lower than on other screens. Trivial, Low: backlog.
| Severity: impact | Priority: how soon to fix | |
|---|---|---|
| High priorityHighest · High | Low priorityMedium · Low | |
| High severityBlocker · Critical | Card charged, no order createdCritical · Highest: fix before the release | Loyalty points reset, feature flag still offCritical · Low: review before switch-on |
| Low severityMinor · Trivial | Last year’s date on the sale bannerMinor · High: fix before Saturday’s campaign | Back arrow 2 px out of lineTrivial · Low: backlog |
- Both high: fix first
- Mixed combination: record the reason in the report, such as a feature that is switched off or a highly visible screen
High severity here means Blocker or Critical, low means Minor or Trivial; Major sits between the two rows.
Who sets which
Severity is a judgement about impact, so the tester who found the defect usually proposes it from the evidence. Priority is a business decision, so the product owner, or whoever owns the backlog, sets it, usually with the development lead in defect triage: a regular review where the team decides what happens to each new defect. If your team asks you to suggest a priority, mark it as a suggestion.
- Tester: proposes severity and records the facts priority depends on: frequency, reach, workaround and the affected release.
- Developer or development lead: confirms cause and scope, estimates the effort and risk of the fix, and may correct severity with new technical facts.
- Product owner: sets and changes priority, decides to defer or not to fix, and records why.
- Support and operations: report how often the failure appears in production and for which customers.
- Severity changes only with new evidence; priority changes whenever the context does.
Try it: AI Bug Severity Suggestion Try it: AI Bug Priority Suggestion
Worked example: rating one defect
During regression testing of the pharmacy app, you cancel a paid order by tapping "Cancel order" twice quickly. The refund is credited to the wallet twice. It happens 5 times out of 5 when the second tap comes within 2 seconds, on Android and iOS.
- Impact: the company pays out twice and the stored balance is wrong; finance would have to find and reverse each case by hand.
- Frequency: every time under a stated condition, and double taps are common on a slow network. Any customer who cancels a paid order can trigger it.
- Severity: Critical, because money is lost and stored data is wrong. Not a Blocker: cancelling still works.
- Priority: not yours to set, but you give the product owner the facts above and the Thursday release date. In triage they set Highest, and you plan a confirmation test for the fix.
Title: Wallet: refund credited twice when "Cancel order" is tapped twice
Impact: money - the wallet receives twice the refund; finance reverses it by hand
Frequency: 5 of 5 attempts, second tap within 2 s (Android and iOS)
Reach: any customer who cancels a paid order
Severity: Critical (proposed by QA: money lost, stored data wrong)
Priority: Highest (set in triage by the product owner: release on Thursday)Common mistakes
- Using one field for both, so that "Critical" means urgent to some people and damaging to others.
- Raising severity to get a faster fix. Argue for priority with facts instead; inflated ratings stop being trusted.
- Rating the worst case you can imagine instead of the impact you observed.
- Treating every cosmetic defect as low priority: on a price, a legal notice or a campaign page it can be urgent.
- Changing priority without recording why, so nobody can later tell a decision from an oversight.
- Leaving out frequency and reach, so the product owner has to guess how many customers are affected.
The QA perspective
On a working team you propose severity when you file the defect, using the team's written scale, and you revisit it in triage when developers add technical facts. Four questions settle most ratings: what did I observe, how often does it happen, who can reach it, and is there a workaround?
When you disagree with a priority, ask about the context instead of arguing about the label: "How many customers cancel paid orders each day?" or "Is the flag really off in production?" New facts change decisions; louder ratings do not. Keep a few rated examples from your own product next to the scale, so that new team members rate the same way.
Practice exercise
Rate four defects in a clinic booking app
You are testing a clinic booking app. The release is planned for Sunday, and a campaign advertising the new online payment starts the same day. For each defect in the material, propose a severity, suggest a priority with one sentence of reasoning, and list the facts you still need.
Then mark the mixed combinations and write the reason you would record for each. Afterwards you may compare your answers with the AI severity and priority suggestion tools, as a second opinion rather than the answer.
D1 Online payment: the "Pay" button does nothing on iOS. Android and the
website work. Patients can still book and pay at the clinic.
D2 The booking confirmation e-mail shows "{doctor_name}" instead of the
doctor's name, for every booking.
D3 A patient can open another patient's lab results by changing the number
at the end of the results URL.
D4 Merging two duplicate patient records (an admin function used a few times
a month) deletes the visit history of the second record instead of moving it.- Write the impact of each defect in one sentence.
- Note what you know about frequency and reach, and what you do not.
- Propose a severity, checking the scale from Blocker downwards.
- Suggest a priority and name who confirms it.
Show the model answer
D1: Major. Online payment fails for every iOS user, but patients can still book and pay at the clinic, and no money or data is lost, so it is not Critical. Priority Highest, because the campaign advertises online payment on release day; the product owner confirms it. Not a mixed combination, because Major sits between the groups. Still needed: the share of patients on iOS (if it is most of them, the team may rate it Critical).
D2: Minor, because the booking itself is correct. Priority High: every patient sees the broken e-mail on campaign day. A mixed combination; the reason to record is visibility to all patients during the campaign. Still needed: whether other e-mails, such as reminders and cancellations, show placeholders too.
D3: Critical, because personal health data is exposed to other users. Priority Highest, and tell the security owner at once. Still needed: whether the defect is already in production; if it is, real patients' data may already have been exposed, and the security owner decides whether to handle it as a security incident. Prove it with test accounts only and stop at the first proof.
D4: Critical, because patient data is lost, even though few administrators use the function. Priority may be Medium if the product owner suspends merging until the fix and any lost histories can be restored from backups; that is a mixed combination, so record the suspension and a review date. If merging must stay available, the priority is High. Still needed: whether the defect is already in production and, if so, whether the backups contain the deleted histories.
Frequently asked questions
Can a defect have low severity and high priority?
Yes. A wrong date on a campaign banner or a misspelled product name in a launch announcement breaks nothing, but every visitor sees it. Priority depends on business context such as visibility and dates, not only on impact.
Who decides when the tester and the developer disagree about severity?
Bring the evidence to triage. The developer may know facts you do not, such as data corrupted behind the scenes, and you may know effects on users that they did not see. If the disagreement remains, the test lead or the triage group decides once and records the reason. Severity is not the place to negotiate schedules; that is what priority is for.
Should frequency change the severity?
Mostly no: severity follows impact, and frequency feeds priority. Some scales, including the one in this lesson, do use reach as a tiebreaker, for example Major instead of Critical when only a few users are affected. Agree on the rule, write it into the scale with examples, and record frequency and reach in the report either way.
What do P0, P1, P2 and P3 mean?
They are a numbered priority scale that many teams and tools use, from P0 (fix immediately) to P3 (backlog). They express priority, not severity. If your tracker uses words instead, keep a written mapping, for example P0 to Highest and P3 to Low. Other trackers number differently, for example P1 to P5, so read your tracker's definitions.
References
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesA standard vocabulary and attributes for classifying software anomalies — defects, failures and their impact (listed by IEEE as inactive-reserved).
Practise with Mutqan tools
Get a suggested severity (Blocker / Critical / Major / Minor / Trivial) with justification from Mutqan AI.
Get a suggested priority (P0–P3) considering business impact, affected users, deadlines and severity, from Mutqan AI.
Turn rough notes into a complete bug report: steps to reproduce, expected vs actual, environment, severity and attachments checklist.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.