A bug that corrupts database records during a bulk import is Critical severity. If that import runs once at onboarding by a single admin with a workaround available, it might legitimately wait until next sprint while a partner's name misspelled on the homepage ships as a hotfix today. Severity and priority are separate dimensions, and this article covers how to apply both: the four-level severity scale, what drives priority decisions, and the two quadrants of the 2×2 matrix that trip up most junior QA engineers.
What severity actually means
Severity measures the technical impact of the bug. How badly does this defect damage the system? Data loss, a crash, a broken payment flow: these are high severity. A misaligned button label, a typo in a tooltip: those are low severity.
Severity lives purely in the technical domain. It doesn't care about the release schedule, the marketing campaign, or how many people will see it. It answers one question: how broken is this, objectively?
The classic four-level severity scale most teams use:
Critical: the bug makes something completely nonfunctional, corrupts data, creates a security vulnerability, or crashes the application. A user cannot proceed. There is no workaround. Example: clicking "Place Order" shows a success screen, but the order is never written to the database. Major: a significant feature is broken or severely impaired. A workaround exists, but it's awkward or not obvious. Example: exporting a report to CSV produces a file with garbled encoding for any name containing a non-ASCII character. Minor: the functionality works, but something is wrong in a way that affects user experience without preventing the task. Example: the "Reset Password" confirmation email says "Your password as been reset" instead of "has been reset." Trivial: cosmetic, negligible functional impact. No user is blocked. Example: a footer copyright year reads 2024 instead of 2026.You, as the QA, set the severity. This is your professional judgment call, and it should be defensible based on observable impact, not feelings.
What priority actually means
Priority measures business urgency. How soon does this need to be fixed, relative to everything else on the backlog?
Priority is not your call alone. A product manager, engineering lead, or project owner typically owns priority, because it requires knowledge of the release schedule, business commitments, and risk tolerance that QA often doesn't have full visibility into.
That said, your severity assessment feeds directly into their priority decision. If you mislabel severity, you're feeding bad data into a business decision.
In practice, small teams blur these lines. A QA lead might set both on a bug. That's fine. The key is to keep the reasoning separate: "this is technically bad for these reasons" versus "this needs to ship by Friday for these reasons."
The 2x2 matrix: where it gets interesting
The obvious cases are easy. A checkout crash on the main payment path? High severity, high priority, fix it now. A misaligned pixel on an admin page nobody uses? Low severity, low priority, it can wait.
The interesting cases are the two corners everyone misses.
High severity, low priority. Imagine you're testing an enterprise application with a bulk data import feature used by database administrators to migrate legacy data. You find a bug: if the import file contains a column with null values in a specific position, it corrupts the imported dataset.That's Critical severity. Data corruption is as bad as it gets.
But the feature is used once during initial onboarding by a single technical user, always under supervised conditions, and a workaround exists (remove null values from that column before importing). The next release is a month out, and there are five higher-traffic flows with active bugs competing for developer time.
Priority? Medium, maybe even Low for this particular sprint.
The severity doesn't change. The data corruption is still Critical. But the business decision to schedule it later than a Major bug in the user-facing checkout flow is completely rational.
Low severity, high priority. Your company just launched a co-branded product with a major partner. On the homepage, the partner's name is spelled incorrectly. One letter transposed.Severity? Trivial. No user is blocked. No data is at risk. The application functions perfectly.
Priority? Critical for this release. Legal, partnership, and marketing all care about this before the product manager has finished their morning coffee. It goes into the hotfix queue ahead of a Major bug in a secondary workflow.
This is the case that trips up junior QAs most often. They see "Trivial severity" and assume low priority, then get confused when it's fixed in two hours while their Major bug sits untouched.
Real examples of all four quadrants
Let's put concrete scenarios to all four cells of the matrix.
High severity + High priority: During regression testing, you find that submitting the password reset form with a valid email returns a 500 error and the reset email is never sent. Users are locked out with no recovery path. This ships Monday. Fix it today. High severity + Low priority: The application's audit log export, used by compliance officers to generate quarterly reports, produces a malformed file if the date range spans more than 18 months. This is genuinely bad (data integrity risk), but the next export window is 10 weeks away, a workaround exists (run two exports and merge), and the compliance team has been briefed. It goes on the next sprint's backlog, not this one. Low severity + High priority: Three weeks before the app's public launch, you notice the meta title tag on the landing page reads "Untitled Document," a template placeholder that was never updated. Zero functional impact. But it'll appear in Google search results and social share previews starting launch day. SEO, marketing, and the CEO care. It's fixed this afternoon. Low severity + Low priority: The tooltip on the advanced filter panel says "Click to exapnd" instead of "expand." It's been there for six months. It'll get fixed in a UI pass next quarter. Nothing about this is urgent.Who sets what, and why it matters
The division of ownership is worth stating clearly.
QA sets severity. You observed the bug, you tested the impact, you know what the system is supposed to do. You're in the best position to judge how broken something is technically. Own that call. If a developer pushes back on your severity label, be prepared to explain your reasoning: "I marked this Critical because it results in data loss in the affected scenario, which by our severity definitions puts it in that tier."
Product or management sets priority. They have context you don't: which customers are affected, what commitments exist, what the competitive pressure is, what the sprint capacity allows. Respect that this is their call.
Where things go wrong: QAs who set Low severity on everything to avoid conflict, or who assume that because they found it, it must be Critical. Both patterns erode trust. Accurate severity is part of your professional output, treat it seriously.
How to argue for priority when someone pushes back
You've logged a Major bug in a core user flow. The PM responds: "We'll look at it next sprint." You think it needs to ship this week.
The way to make this case: frame it in user and business impact, not technical pride.
Weak argument: "But this is a Major bug, it has to be fixed now."
Stronger argument: "This breaks the export flow for any user with more than 500 items. Based on our user data, that's roughly 30% of active accounts. If we ship Friday without fixing this, we'll get support tickets. I'd rather flag it now than handle it post-release."
Give the PM something to weigh. They're making a risk trade-off. Your job is to put the right information on the table, not to make the final call. If they hear the business case and still decide to defer it, that's a legitimate product decision. Document that the bug was known and triaged, log it, and move on.
The five-level scale vs the four-level scale
Some teams use five severity levels: Critical, High, Medium, Low, Trivial. Others use four (Critical, Major, Minor, Trivial). Some use three (High, Medium, Low).
The scale you use matters less than consistent application within your team. The problem with larger scales isn't the number of levels. It's that teams end up debating whether something is High or Medium instead of triaging bugs. If your team spends 20 minutes arguing over whether a bug is Minor or Trivial, the scale has more granularity than your process can support.
For most teams, four levels work well. Five is appropriate if you have a large QA organization where severity feeds automated SLA timers (e.g., Critical bugs must be acknowledged within 2 hours, High within 24 hours). Three levels work in fast-moving early-stage teams where nuance is a luxury.
Pick a scale, document what each level means with concrete examples, and apply it consistently. Consistency matters more than precision.
Writing severity in a bug report that doesn't get argued
The reason severity gets contested in triage meetings is almost always the same: the severity label is there, but the reasoning isn't.
"Severity: Critical" invites a debate. "Severity: Critical: clicking Submit silently drops the form submission with no feedback; users believe their action succeeded, but nothing is saved" does not.
Write severity like a short verdict with evidence. One or two sentences. State the impact, state why it falls into that tier.
Here's the pattern: [Severity level]: [what the system does wrong] [who is affected and how] [why this tier and not a lower one].
Applied:
Bad: Severity: Major
Better: Severity: Major. Password reset flow fails for all users attempting to reset via mobile browser. Users are blocked from account recovery on mobile; desktop still works, which is the workaround.
This phrasing does three things: it justifies the label with the impact, it scopes who's affected, and it acknowledges what makes it Major rather than Critical (a workaround exists). Anyone reading the ticket understands the severity decision without asking you to explain it.
How to apply this starting Monday
When you log your next bug, slow down at the severity and priority fields instead of clicking the first option that feels right.
Ask yourself: what actually breaks here, and for whom? If a user hits this bug, can they complete their goal another way? Does it affect all users or a specific segment? Does it corrupt data or just inconvenience someone?
That answer is your severity. Write a one-sentence justification next to the label.
Then look at the ticket backlog. What's shipping this sprint? Who's affected by this bug relative to the rest of the bugs waiting? Draft a priority suggestion in a comment, not as a demand, but as input: "Given that this affects the core payment path and we're releasing Friday, I'd suggest making this a sprint priority."
Over time, this practice does something visible: your triage decisions stop getting reversed. PMs stop overriding your labels. Developers stop challenging your Critical calls. That's not because you got lucky. It's because you separated two concepts that most junior QAs collapse into one, and started communicating the distinction clearly.
That's the triage skill that gets noticed.
→ See also: The Anatomy of a Bug Report That Developers Actually Fix | How to Write a Test Case: Format, Examples, and Common Mistakes
