The login page throws an error for one specific browser. You log it. But what do you call it? Critical? High? Or one of those medium bugs that sits in the backlog until someone eventually closes it as “won’t fix”?
Most testers make a judgment call. And most of the time, that call is wrong. That’s because they do not know the product, but because nobody ever gave them a consistent way to think through it. IBM discovered that defects discovered after release cost up to 30 times more to fix than those caught during the design. That gap involves more than just when teams find bugs. The real cost comes from what happens in the minutes after discovery, when someone has to decide how serious this actually is:
- A critical bug buried under a pile of “Major” tickets sits unresolved for days.
- A cosmetic typo flagged as “Critical” pulls a developer off real work to fix something three users will ever notice.
This guide walks you through the four severity levels every QA tester should know, how to tell them apart when the call is not obvious, and clears up the one distinction that trips up almost everyone: bug severity vs. priority.
What Is Bug Severity, Anyway?
Severity is purely a technical measurement. It tells you how badly a bug breaks the system, nothing more. It has nothing to do with deadlines, customer complaints, or how loudly someone escalated the ticket in Slack.
ISTQB defines severity as the degree of impact a defect has on the development or operation of a component or system.
Does this bug make the product unusable, break a key feature, add friction, or just look slightly off?
The reason a clear definition matters is consistency. Two testers examining the same bug should land on the same severity level independently. If they differ, the problem usually is from the team working with different internal definitions for the same words.
This is what a framework solves. Not skill. No experience. Just shared criteria that everyone applies the same way.
The Four Severity Levels are Explained With Real Examples
Most QA teams use a four-tier model. Some add a fifth “blocker” tier above critical, but for day-to-day testing, these four levels cover the vast majority of defects you’ll log.
Critical
A critical bug stops the application from functioning, blocks testing tracks entirely, or causes irreversible harm such as data loss or a security breach. Workarounds simply do not exist here. The system is unusable for the affected functionality.
Example: A user submits a payment on checkout, the page hangs, and the order never completes. You see no confirmation, no error message, absolutely nothing. The customer doesn’t know if they were charged. That’s critical. The error directly impacts revenue, shatters trust, and potentially triggers compliance issues, all at once.
Other critical examples:
- The app crashes upon launch for all active users
- Login functionality fails across every major browser
- A security flaw actively exposes customer payment data
- The system permanently deletes data instead of properly archiving it.
If you’re staring at a bug and wondering if anyone can actually use the product, and the answer comes back negative, you have definitely uncovered a critical defect.
High (Major)
A high-severity bug keeps the overall system running while completely breaking a major feature or function. Users can technically still navigate the app, yet they will find a significant piece of functionality entirely broken or highly unreliable.
Example: The checkout flow works, but applying a discount code fails to subtract the amount from the total. The order still goes through, payment still processes, but the core promise of the feature (a working discount) completely fails. Customers always notice, and 46% stop buying it.
Other high-severity examples:
- The search function returns zero results for valid queries
- A core API endpoint intermittently returns malformed data
- File uploads fail for files over a certain size threshold without triggering an error message
- A key dashboard widget actively displays incorrect data
The test here is simple: does this bug stop users from completing what they came to do? If yes, and there’s no easy workaround, you’re likely looking at a high-severity issue.
Medium (Moderate)
Medium-severity is where most of the debate happens. The system is still working, users can get things done, but something is broken or degraded enough that people notice. Usually, there is a workaround, or the impact only hits a specific subset of users rather than everyone.
Example: A “remember me” checkbox on the login screen stops keeping users logged in after they close their browser. Nobody loses data. They just have to log in again every time, which adds friction for users who specifically ticked that box to avoid exactly that. It is worth fixing, but it is not stopping anyone from using the product.
Other medium severity examples:
- Table sorting works correctly, but the sort indicator arrow doesn’t update visually
- An email notification is delayed by several minutes instead of being sent instantly
- A filter resets unexpectedly when navigating back to a previous page
- Form validation permits an edge-case input that should fail, but doesn’t break anything downstream
Medium bugs frequently spark the most debate among teams. When in doubt, ask yourself whether the bug meaningfully degrades the experience or just adds minor friction. Degradation leans medium. Friction without consequence often leans low.
Low (Minor/Cosmetic)
A low-severity bug has little to no actual impact on core functionality. These represent visual glitches, basic typos, alignment issues, or small inconsistencies that don’t affect how the system performs.
Example: A button on the pricing page is misaligned by a few pixels on the tablet view. The element remains clickable, still does what it’s supposed to do, and most users won’t even notice. The alignment just looks slightly off.
Other low-severity examples:
- A typo in a tooltip or help text
- Noticeably inconsistent font weight on a secondary heading
- A loading spinner that displays for half a second longer than it should
- Color contrast that’s slightly off on a non-critical UI element
Low-severity bugs still matter. Teams log them, track them, and eventually fix them. They just don’t get fixed today.
Severity vs. Priority: The Distinction that Trips Everyone Up
Here’s where a lot of junior testers get stuck, and honestly, plenty of senior ones, too, when they’re moving fast. Severity and priority sound like they should mean the same thing. They don’t.
Severity is about technical impact. Priority handles business urgency, and the product owner, project manager, or engineering lead usually makes the decision, not the tester alone.
A bug can easily be high severity and low priority. A bug can also be low severity and high priority. They operate independently, and assuming they always align is one of the most common classification mistakes in QA.
High severity, low priority: A security vulnerability exists in a feature awaiting customer release. The technical impact is serious, but since zero real users are affected yet, the team can schedule the fix for the next sprint instead of dropping everything right now.
Low severity, high priority: A typo appears in the company logo or tagline on the homepage. The functional impact is basically zero. Customer data remains perfectly safe, and system stability is fully intact. But it’s embarrassing. The mistake remains visible to every visitor, and leadership wants the typo fixed before the next investor call. Severity is low. Priority is through the roof.
This is exactly why severity and priority need to live in separate fields in your bug tracking tool, whether that is Jira, Kualitee, or anything else your team runs on. When they get collapsed into a single field, whoever logs the bugs ends up making a business judgment they are not supposed to be making. The product team loses the raw technical data they need,d and triage decisions start getting made on incomplete information without anyone realising it.
A Simple Way to Remember It
Severity answers one question: How bad is this bug?
Priority answers a completely different one. How soon do we need to fix it?
One is a technical assessment you make as a tester. The other is a business decision someone else often makes, using your severity rating as one input among several.
How to Classify Severity Without Second-Guessing Yourself
Once you’ve mastered the four levels down, the actual decision usually comes down to asking the same four questions in order.
- Does this block usage entirely? If yes, you’re looking at critical. Stop right there.
- Does this break a core feature with no workaround? If yes, you’re in high-severity territory.
- Is there a workaround, or is the impact limited to an edge case? If yes, you’re likely at medium. The feature still technically works, just with some friction.
- Is the impact purely visual or cosmetic, with zero functional consequence? If yes, you have a low-severity issue.
Walking through these four questions in order, instead of jumping straight to a gut feeling. It guarantees severity ratings stay consistent across a team. This approach accelerates onboarding for new testers, since you’re handing them a repeatable process instead of asking them to develop “instinct” on day one.
These habits build accuracy over time:
- Before you assign a severity level, write down exactly what breaks and for whom. If you cannot state the impact in one sentence, you have not tested the edge cases thoroughly enough to classify them yet.
- Do not assume a workaround exists; test it. A lot of bugs get under-classified because someone writes “user can just refresh the page” without confirming that refreshing actually fixes anything.
- Severity is not permanent. A bug sitting at medium in a beta environment can quietly become a high-severity issue the moment that feature ships to your full user base. Revisit the rating when context changes, not just when someone on Slack starts complaining.
- The most common source of inconsistent ratings is not bad judgment — it is two testers using the same word to mean different things. A short team glossary fixes this faster than any amount of individual coaching sessions.
Why Getting this Right Actually Matters
Consistent severity classification directly affects three things teams feel every sprint:
- How fast defects get triaged
- Whether release decisions are based on real risk or the loudest complaint
- How much do developers trust the bug reports coming from QA
When those ratings are reliable, engineering leads can scan open defects and immediately understand where the risk sits, without re-investigating every ticket themselves. When ratings fluctuate, every defect list needs a second pass before anyone can trust it, which slows down exactly the kind of fast triage that QA is supposed to enable.
This is also where the test management platform your team uses either holds things together or quietly makes the problem worse. When severity lives in a spreadsheet, it gets filled in inconsistently, left blank under deadline pressure, and interpreted differently by every tester on the team. By the time a release is ready to ship, nobody actually knows which open defects are genuinely critical and which are just the ones someone escalated loudly last week.
Kualitee keeps severity and priority in separate, required fields so the data stays clean without relying on everyone remembering to do it right. Engineering leads get a real-time view of open defects by severity level, which means triage takes minutes instead of a second pass through every ticket.
If your team is making release calls based on a spreadsheet or scattered Jira comments, you already know the problem.
FAQs
Are bugs and defects the same thing?
For most teams, yes. The technical distinction is that a defect lives in the code, and a bug is what you actually see when that defect surfaces during testing. But testers and developers use the terms interchangeably, and nobody stops a standup to correct it.
Who decides the severity of a bug, the tester or the developer?
The tester who found it usually makes the first call, since they saw the actual behavior firsthand. That rating can get revised during triage when developers or QA leads have more context, but the initial classification belongs to whoever observed the impact directly. Developers adjusting severity without that first-hand observation is one of the ways ratings drift.
Can severity change after a bug is first logged?
Yes, when the situation changes. A bug affecting ten beta users carriea s different weight than the same bug reaching your entire customer base after a full release. Severity is supposed to reflect current impact, not the circumstances from the day it was first reported.
Is there a fifth severity level above critical?
Some teams use a “blocker” level above critical for defects that halt all testing or development work entirely, not just the affected feature. Whether you need a fifth tier depends on your team’s size and release complexity. Most teams operate fine with four levels.
