What Is a Bug, Really? Severity vs. Priority Explained

Two arguments happen on almost every team. The first is "Is this actually a bug?" The second is "Okay, but do we fix it now?" People argue past each other because they are answering different questions without realizing it. This guide gives you a small, plain-English framework that settles both — and we will run one little app through the whole thing so you do it yourself, once, start to finish.

No jargon you have to memorize. Just three questions, asked in order.

What actually counts as a bug

Start with a definition you can lean on: a bug is software behaving differently from how it is supposed to behave.

The load-bearing words are "supposed to." A bug is a gap between what the software was intended to do and what it actually does. That is it. If there is no gap — if the software is doing exactly what it was designed to do — then whatever you are looking at, it is not a bug.

That distinction sounds obvious until you are staring at something annoying and have to decide what it is. Three quick cases:

• A valid email address gets rejected at sign-up. The form is supposed to accept valid emails. It doesn't. That gap is a bug.

• You wish the "Add" button were green, but the design spec says blue, and it is blue. There is no gap between intended and actual. The software is doing what it was told. This is a preference, not a bug.

• The software does exactly what the spec says, but the spec was a bad idea. No gap between intended and actual either — the intention itself was wrong. This is a design problem or a feature request, not a bug.

Why does the label matter? Because bugs and feature requests are handled differently. A bug is a broken promise — the software said it would do something and didn't — so the job is to fix it. A feature request is a new promise — someone wants the software to do something it never claimed to — so the job is to weigh it against everything else you could build.

How to decide: ask one question first — "What was this supposed to do?" If the software fails at that, you have a bug. If it succeeds at that and you simply want it to do something else, you have a preference or a feature request. Sort that out before anything else, because the next two questions only apply to real bugs.

The two questions that sort every bug

Once you agree something is a bug, two more questions decide what happens to it. Teams constantly blur them together, and that blur is where fights start.

Severity: how bad is it? This is a technical question about the damage. Does the app crash? Does anyone lose data? Does the whole feature stop working, or is one pixel out of place? A crash that wipes someone's saved work is high severity. A slightly misaligned icon is low severity. Severity is about the size of the harm when the bug happens.

Priority: how soon should we fix it? This is a business question about the queue. Given everything else the team could be doing, where does this bug sit? Right now, this sprint, someday, or never? Priority is about urgency and order.

Here is the part beginners are surprised by: severity and priority are independent. A bug can be badly damaging but not urgent, or barely damaging but extremely urgent. They do not move together. Keeping them separate is the whole skill — because the interesting, argument-causing bugs are exactly the ones where the two answers disagree.

How to decide: for every confirmed bug, answer two separate questions on purpose — "How bad is the damage?" (severity) and "How soon does it need to be fixed relative to everything else?" (priority). Write them down as two answers, not one. If you only ever produce a single number, you have quietly merged two questions and you will mis-sort the tricky cases.

The four combinations, with a plain example each

Because severity and priority are two separate yes/high-or-no/low answers, every bug lands in one of four boxes. Here is the 2x2, with one everyday example in each square.

	Priority: fix soon	Priority: fix later
Severity: high (big damage)	Checkout button is broken, so nobody can pay. Damaging and urgent — this is the one you drop everything for.	App crashes and loses data, but only in an experimental setting almost no one turns on. Serious harm, but it rarely happens, so it waits.
Severity: low (small damage)	Company name is misspelled on the homepage banner. Nothing breaks, but everyone sees it and it looks careless — fix it fast.	A tooltip is worded a little awkwardly on a settings page few people visit. Minor, and it can sit in the backlog.

Notice the two off-diagonal squares — high-severity/fix-later and low-severity/fix-soon. Those are the mismatches. They feel wrong the first time you meet them, and they are exactly where teams argue, because someone is reading severity as if it were priority.

How to decide: place each bug in a square by answering the two questions separately, then let the square tell you what to do — not your gut reaction to how scary or how trivial the bug sounds on its own.

Walking one small app through the whole thing

(Developed example — a simple scenario.)

Imagine a tiny to-do list app called Tidy. It just launched. Over one morning, three reports land in the team's inbox. We will run each one through the same three questions: Is it a bug? How bad? How soon?

Report 1 — "The 'Add task' button should be green. Blue looks cold."

First question: what was this button supposed to do, and what color was it supposed to be? We check the design spec. The spec says the button is blue, and it is blue. There is no gap between intended and actual — the app is doing exactly what it was designed to do. So this is not a bug. It is a preference. It might be a perfectly good idea, but it goes into the feature-request pile to be weighed against other improvements, not into the bug list. We never even get to the severity and priority questions, because those only apply to real bugs. Sorted: preference / feature request.

Report 2 — "If I turn on 'Experimental sync' in settings and then rotate my phone, the app deletes all my saved tasks."

First question: what was the app supposed to do? Keep your tasks safe. Deleting them on a screen rotation is clearly a gap between intended and actual — this is a real bug. Now the two separate questions. How bad? Losing all of a person's saved tasks is about as damaging as this little app gets, so severity is high. How soon? The team checks who is affected: "Experimental sync" is off by default, hidden two menus deep, and the launch analytics show almost nobody has switched it on. The damage is severe but it is landing on a tiny number of people through a rare path, so it can be scheduled rather than treated as an emergency — priority is lower. Sorted: high severity, low priority — the top-right square.

Report 3 — "The homepage banner says 'Tidyy' instead of 'Tidy.'"

First question: was the banner supposed to spell the product name correctly? Yes. It doesn't. Real bug. How bad? Nothing crashes, no data is lost, every feature still works — the harm is basically zero, so severity is low. How soon? This is the first word every new visitor reads on launch week, it makes the whole product look careless, and it is a five-minute fix. So priority is high. Sorted: low severity, high priority — the bottom-left square.

Line the three up and the framework has done real work. One report was not a bug at all. The other two are both genuine bugs, yet they sort in opposite directions: the scary-sounding data-loss bug waits, and the trivial-sounding typo gets fixed first. If the team had used one gut-feel number per report, they would almost certainly have rushed the data-loss bug and shrugged off the typo — exactly backwards for launch day.

How to decide: run every incoming report through the same three questions in the same order — bug or not → how bad → how soon — and trust the sort even when it feels counterintuitive. The order is what protects you from reacting to the loudest word in the report.

Where this connects to discovery

There is a quieter lesson hiding in Report 1. The reason we could say "not a bug" in seconds is that someone had written down what the button was supposed to be. The spec settled the argument. When teams have no clear record of what the software was meant to do, every one of these three questions turns into an opinion contest — and "is this even a bug?" becomes unanswerable.

That is the ShiftQuality throughline: a lot of what looks like a testing problem later is really a discovery gap earlier. You cannot measure a gap against an intention that was never written down. Deciding what the software is supposed to do is not paperwork you do after the fun part — it is the thing that makes every later bug call fast and calm instead of a fight.

How to decide: if your team keeps arguing about whether things are bugs, the fix usually is not a better argument in the moment — it is writing down, up front, what each piece of the product is supposed to do.

What to do next

You now have the concept: define a bug by the "supposed to" gap, then sort real bugs with two independent questions. The natural next step is turning a sorted bug into a report a team will actually act on. Severity and priority are two of the fields that make a bug report land instead of languish — see Writing Bug Reports That Actually Get Fixed for how to put this to work, and Bug Report Template: What Makes One Useful for a fill-in starting point. If reports are landing on you and the numbers look scary, How to Read a Test Report Without Panicking helps. And if you want the bigger picture of what "quality" even means here, start with What Is Software Quality?

Next time a report comes in, say the three questions out loud — Is it a bug? How bad? How soon? — and let the answers, not the panic, decide the order.

Sources

• Tidy to-do app scenario — a simple composite example built for this article to illustrate the framework. It is not a real product or a documented case.

Keep learning. This article is part of the Start Here path in the ShiftQuality Learning Center.