DEV Community

BugIt
BugIt

Posted on Originally published at bugit.hashnode.dev

Severity is not priority: a practical guide for people who file bugs

#testing #qa #softwareengineering #productivity

Most trackers have two fields that look like they mean the same thing: severity and priority. Teams that treat them as one end up arguing in triage about words instead of bugs. Teams that keep them apart move faster, because each field answers a different question and is owned by a different person.

The two questions

Severity: how bad is it when it happens? This is about the bug's effect on the product and its users. The person who found it is usually best placed to judge, because they saw it.

Priority: how soon should we fix it? This is a scheduling decision. It weighs severity against everything else: how many people hit it, whether a release is coming, whether a workaround exists, what else is on the board. It usually belongs to whoever runs triage.

A crash in a settings page almost nobody opens can be high severity and low priority. A typo in the checkout button is low severity and may be top priority the week before a launch. Both are correct.

A severity scale you can actually use

Four levels are enough for most teams. Write down what each means in terms of what a user loses:

  • Blocker: a core task cannot be done at all, with no workaround. Data loss, a crash on launch, payments failing.
  • Major: a core task is broken or wrong, but there is a workaround, or it affects a significant group of users.
  • Minor: something works incorrectly in a way that is annoying but does not stop anyone.
  • Cosmetic: layout, wording, alignment. Nothing is wrong except how it looks.

Give a reason

A bare "Critical" invites a debate. One sentence of reasoning ends it before it starts:

Major: annual upgrades that use a coupon are charged the full price; customers can still buy monthly.

Now the triager can agree, disagree with a specific point, or adjust priority knowing exactly what you saw.

Common mistakes

  1. Rating by frustration. A bug that took you two hours to pin down is not more severe because it was hard to find. Rate the effect, not the effort.
  2. Rating everything high to get attention. It works once. After that, high ratings from you get discounted.
  3. Leaving severity to the developer. They will set it, but without your view of how it showed up to a user. Give your rating; let them change it.
  4. Mixing in priority words. "Severity: urgent" is a priority statement. Keep the fields separate and both become more useful.

How BugIt helps with this

BugIt is a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal. When it drafts a bug report from what you describe, it suggests a severity from the symptoms and shows its reasons. The decision is yours: keep it, change it, or overrule it. The reasoning goes into the draft, so the triager sees why.

It also fills in the rest of the report the way this guide asks for: steps, expected result and actual result, and it tells you when any of them look thin. Nothing is filed until you have read the draft and typed FILE IT.

The two minute introduction:

BugIt: a QA agent that writes the bug report for you

Try BugIt

Top comments (0)