Severity vs Priority in Bug Tracking: A QA Guide

Severity measures how badly a bug breaks app. Priority measures how urgently it needs to be fixed. Severity is technical impact. Priority is business urgency. They're related but independent. A crash that only happens on a rare device (high severity, low priority) and a typo on home screen (low severity, high priority) need different treatment.

Most severity vs priority guides use same generic examples. This one covers how severity and priority work on mobile teams specifically, with real mobile examples, a triage matrix that feeds directly into your bug tracking tools, and classification mistakes that slow down releases. Getting priority and severity example classifications right is one of most practical testing skills a QA engineer can build.

What is bug severity?

Bug severity is degree of technical impact a defect has on app. It measures how much damage bug does to functionality, stability, or data integrity. Severity is set by QA engineers based on what bug actually breaks.

Standard bug severity levels:

The severity of bug classification doesn't change based on business context. A crash is a crash whether it happens during a product launch or a quiet Tuesday. Severity is objective and technical. Your bug severity definitions and bug priority definitions should be documented so whole team applies them consistently.

What is bug priority?

Bug priority is order in which a defect should be fixed. It's set by product managers, engineering leads, or QA leads based on business urgency, user impact, and release timelines. Priority is subjective and context-dependent.

Standard bug priority levels:

Priority can change. A P3 bug becomes P1 if a major client reports it. A P1 bug becomes P3 if a hotfix ships a workaround. Bug severity stays constant. Bug priority shifts with business context.

How do severity and priority interact?

Severity and priority don't always align. The four combinations each require different handling.

The high severity and low priority example is one that trips up most teams. QA flags a crash (severity is high), but product says scenario is so unlikely that it doesn't warrant immediate attention (priority is low). Both are right. The bug severity definition says "this is a crash." The priority says "almost no users will hit it."

The low priority high severity example works other way too. A low severity and high priority example like logo typo is technically trivial but CEO just emailed about it. Priority goes up.

What does severity vs priority look like on mobile?

Mobile adds complications that web apps don't have. Here are examples of severity and priority specific to mobile QA:

Example of high severity and low priority on mobile: A crash occurs on a Samsung Galaxy A04 running Android 11 when user enables dark mode in accessibility settings. High severity (crash). Low priority (that device/OS combination represents 0.3% of your user base and trigger requires navigating through system settings).

High priority and low severity example on mobile: The app icon renders at low resolution on iOS 18 after an asset pipeline change. Low severity (app works fine). High priority (every iOS 18 user sees blurry icon on their home screen, and app store screenshots look unprofessional).

Example that changes priority based on context: A deep link from a marketing email opens home screen instead of product page. Normally P3. But if marketing team just sent email to 500,000 subscribers, it becomes P1 within minutes.

How should you run severity vs priority triage on a mobile team?

Triage is where severity and priority get assigned or adjusted. For mobile teams shipping weekly, a 15-minute daily standup triage works better than a weekly 1-hour meeting.

The triage workflow:

1. QA files bugs with severity based on technical impact. QA owns severity.
2. In triage, product and engineering review new bugs and assign priority. Product owns priority.
3. P1 bugs get assigned to a developer immediately. P2 bugs go into current sprint. P3 and P4 go to backlog.
4. After each release, re-triage backlog. Some P3 bugs become P2 when a related feature is being worked on.

On mobile, one extra step matters: verify bug is real and not a flaky test false positive. If your test automation suite reports a "blocker" that's actually a broken selector, you waste triage time on a non-bug. Stable automation (like Vision AI that doesn't depend on selectors) reduces noise in your bug pipeline.

What are common severity vs priority mistakes?

• Treating severity and priority as same field. Jira removed severity field at one point, forcing both concepts into one "Priority" field. This conflates technical impact with business urgency. Add severity back as a custom field.
  
  
• QA setting priority instead of severity. QA understands technical impact. Product understands business urgency. When QA sets both, bugs get classified by technical criteria only, and business context gets missed.
  
  
• Inflating severity to get bugs fixed faster. If QA marks everything as "Blocker," developers stop trusting severity labels. Stick to definitions. A cosmetic issue is S5 even if it's on home screen.
  
  
• Ignoring bugs severity distribution. If 80% of your open bugs are S4/S5 and only 5% are S1/S2, your app is stable but your backlog is cluttered. If 30% are S1/S2, you have a quality problem. Track defect density by severity to spot trends.
  
  
• Not re-triaging after releases. A P3 bug reported two months ago might now affect a flow you're redesigning. Re-triage makes sure priority reflects current context.
  
  

How do bug tracking tools handle severity and priority?

Different bug tracking tools handle these fields differently:

• Jira: Priority is built in. Severity is a custom field you add. Most mobile teams add it.
• Azure DevOps: Both Severity and Priority are built-in fields.
• Linear: Uses Priority only (Urgent, High, Medium, Low, No Priority). Severity must be added via labels.
• GitHub Issues: Uses labels for both. You create your own severity and priority labels.

Pick a tool that supports both fields natively or lets you add severity as a custom field. Using one field for both concepts creates ambiguity that slows down triage. Tools like Drizz reduce volume of bugs entering your tracker by catching regressions in automated tests before they're filed as bugs, keeping your severity/priority pipeline focused on real issues.

‍

FAQs

What is difference between severity and priority?

Severity measures technical impact (how badly bug breaks app). Priority measures business urgency (how quickly bug needs fixing). QA sets severity. Product sets priority. A crash on a rare device is high severity, low priority. A visible typo is low severity, high priority.

What are bug severity levels?

Standard bug severity levels are S1 (Blocker: app crashes, no workaround), S2 (Critical: major feature broken, workaround exists), S3 (Major: feature works incorrectly), S4 (Minor: small defect, minimal impact), and S5 (Trivial: cosmetic only). Bug severity definitions should be documented and agreed on by whole team.

What is a high severity and low priority example?

A crash that only triggers when a user enters 500+ characters in a search field. The severity is high (it's a crash). The priority is low (no real user would do this). Another example of high severity and low priority: a crash on a device that represents less than 1% of your user base.

What is a low severity and high priority example?

A misspelled company name on home screen. The severity is low (no functional impact). The priority is high (every user sees it and it damages brand perception). A low priority high severity example flips this: a rare crash that affects almost nobody.

Who sets severity vs priority?

QA engineers set severity based on technical impact. Product managers or engineering leads set priority based on business urgency, release timelines, and user impact. Triage meetings align both perspectives. Neither role should set both fields alone.

How do you handle severity and priority examples in Jira?

Jira has Priority as a built-in field but not Severity. Add Severity as a custom field with levels S1 through S5. During triage, QA reviews severity and product reviews priority. Use Jira's filters to surface high-severity bugs that haven't been prioritized yet. This catches software bug priority levels that need attention.