Bug severity vs priority is the first classification question every tester gets asked, and the confusion is understandable because both fields sit next to each other on the same JIRA ticket. The distinction is simple. Severity measures how badly the bug damages the system or the user: crash, data loss, cosmetic glitch. Priority measures how urgently the business wants it fixed relative to everything else. Severity is a technical fact. Priority is a scheduling decision. They correlate often, but not always, and the cases where they diverge are exactly the ones worth understanding.
Severity vs priority: the four quadrants
- High severity, high priority: the app crashes on login for every user. Total impact, fix it now. Nobody debates these.
- High severity, low priority: the app crashes, but only when exporting a report format that analytics says a handful of users touch per month, in a feature scheduled for removal. Technically brutal, commercially minor.
- Low severity, high priority: the company name is misspelled on the login screen, or an Arabic label renders left-to-right in an RTL layout. Nothing is functionally broken, but it's the first thing every user and every reviewer sees. My RTL testing has produced several of these: one-line fixes that still needed to ship before release because they made the product look careless to an entire market.
- Low severity, low priority: a button is two pixels off on one uncommon screen size. Log it, batch it, move on.
Who decides which
Ownership is the part teams skip, and it's the part that prevents arguments. As the tester, I set severity, because I observed the failure and can describe its technical impact objectively. The priority call belongs to whoever owns the backlog, usually the product owner, because it depends on things I can't see from a stack trace: release commitments, customer contracts, what else is in the sprint. I can recommend a priority, and I often do, but recommending and deciding are different jobs. A tester who quietly accepts a severity downgrade, or unilaterally sets everything to highest priority, is doing the wrong half of someone else's job.
How mislabeling erodes trust
Labels are a currency, and inflation ruins currencies. Mark every bug critical and within a month "critical" means nothing; developers start triaging your tickets themselves, which is a polite way of saying they've stopped trusting your judgment. Under-labeling costs the same trust in the other direction: call a data-loss bug minor once, and every future "minor" gets a suspicious second read. The entire value of these two fields is that people can act on them without re-verifying your work. Accurate, boring, consistent labeling is one of the fastest ways a junior tester builds a reputation, because it's visible on every single ticket you file.
A simple rubric
When I'm unsure, I answer two questions separately, in order, without letting the first answer contaminate the second:
- If a user hits this, how bad is their day? Data lost or app unusable: critical. A core flow blocked with no workaround: major. Annoying but there's a workaround: minor. Cosmetic: trivial. That's severity, and it never changes based on deadlines.
- How many users will hit it, how visible is it, and what does the release calendar say? That conversation, with the product owner, sets priority.
Rule of thumb: severity answers "how bad?" and belongs to QA. Priority answers "how soon?" and belongs to the business. Never let one field silently answer the other's question.
Once the two fields stop blurring together, triage meetings get shorter, tickets stop bouncing back with relabeled fields, and your name on a bug report starts meaning the label is right. That's a small thing to be known for, and a surprisingly valuable one.