Tester sets Severity
Pros
- Closest to the observed impact during execution
- Knows whether a workaround exists
- Sees data loss or security issues first
Cons
- May not know the release calendar
- Cannot weigh business commitments
Guide
Severity vs priority
Severity vs priority with examples: severity is how bad the bug is for users; priority is how soon you fix it. They are not the same thing.
Updated 5 min read
Severity: impact on the user
Severity answers: if this ships, how much does it hurt? A typo on the About page is low severity. Data loss on save is critical.
- Critical: crash, data loss, security hole, or blocker with no workaround
- High: major feature broken, workaround is painful
- Medium: feature works but wrong in edge cases
- Low: cosmetic, rare edge case, minor inconvenience
Priority: when to fix it
Priority answers: given everything else in the sprint, when should dev pick this up? A low-severity typo on the CEO demo screen might still be high priority on release day.
Product owners often set priority. Testers usually set severity based on observed impact.
Who sets which field
Product / lead sets Priority
Pros
- Owns the sprint backlog and release dates
- Weighs commercial commitments and demos
- Can defer or escalate based on customer impact
Cons
- Often one step removed from reproduction
- Needs QA evidence to set priority correctly
Severity vs priority with examples
A 4×4 matrix makes triage concrete. Pick the cell that matches the observed behavior and the release context, not the loudest voice in the standup.
Severity × Priority matrix with concrete examples
| Severity ↓ / Priority → | Critical | High | Medium | Low |
|---|---|---|---|---|
| Critical | Payment fails for all users — block release. | Save spinner hangs on timeout, customers lose work — fix this sprint. | Critical data corruption on a beta-only feature — patch after launch. | Crash in a legacy admin tool one analyst uses — schedule next quarter. |
| High | Login broken on Safari before a demo — fix today. | Checkout coupon ignores trailing spaces — fix this sprint. | Search returns stale results after filter change — fix next sprint. | CSV export breaks for an internal admin tool — defer to backlog. |
| Medium | Filter resets after pagination on the demo flow — fix before demo. | Tooltip wrong on a high-traffic page — fix this sprint. | Sort order resets on tab switch — schedule normally. | Edge-case validation message wording — backlog. |
| Low | Misaligned logo on the hero before a CEO demo — fix tonight. | Marketing typo on the pricing page before launch — fix this week. | Inconsistent spacing in the settings page — schedule normally. | Footer copyright year on a rarely visited page — backlog. |
High severity low priority example
An internal reporting job drops rows when a legacy date format is used. Severity is High because data integrity is wrong. Priority is Low because only two analysts use the report and the next release is customer-facing checkout work. The team schedules it for the following sprint instead of stopping Friday's deploy.
Same bug, different fields
Title: Save button spins forever after network timeout.
Severity: Critical — user cannot save work and may lose data.
Priority: High — fix this sprint, but after the production checkout blocker.
They can disagree
Critical severity + low priority can happen when a bug only hits an internal admin tool due next quarter. High priority + low severity happens for visible polish before a launch.
Record both fields. Arguing about one number that tries to mean both just creates confusion. Pair this with defect life cycle so transitions stay clean.
In QA Workspace
When you fail a step, the defect drawer captures severity from your selection. Export maps defects to spreadsheet columns that line up with common Jira CSV imports.