Two different questions Severity asks how badly the product is broken. Priority asks when you are going to do something about it. Teams that collapse them into one field end up arguing about labels instead of fixing software. Here is the scheme Apex Automation Team uses on every cycle, manual or automated.
1. Severity describes impact
- S1 Critical: core functionality unusable, data lost or corrupted, a security exposure, or a full outage, with no workaround. Cannot log in. Payment charges the wrong amount. One customer can see another customer's records.
- S2 Major: a significant function broken or seriously degraded, with a workaround that is impractical or costly. Search returns wrong results. A report will not generate. A screen fails on one supported browser.
- S3 Minor: the function works but behaves incorrectly or awkwardly in a limited way, and there is a reasonable workaround. A confusing validation message. A wrong sort order. A date in the wrong format.
- S4 Trivial: no functional impact. A misaligned element, inconsistent capitalisation, a typo.
Severity is assigned by whoever found the bug, from evidence, and it does not change because the release is close.
2. Priority describes your schedule
- P1 Immediate: work stops until this is resolved, hotfix path if needed.
- P2 High: must be in the current cycle, blocks the release.
- P3 Medium: scheduled soon, does not block the release.
- P4 Low: fix when the area is being touched anyway.
Priority belongs to the product owner, because it is a business decision, not a testing one.
3. All four combinations are normal
High severity with high priority is the easy case: stop and fix. High severity with low priority is genuinely broken but in a corner nobody visits this quarter, so it schedules normally. Low severity with high priority is the typo on the pricing page the day before launch. Low with low is a backlog item, and if it is never realistically going to be fixed it should be closed honestly rather than left rotting.
4. Running a triage that ends
Keep it to four people: product owner, a QA voice, an engineering lead, and someone who talks to customers. Two minutes per new defect. Every defect leaves the meeting with a severity, a priority and a named owner, and that is the only exit condition that matters.
The agenda is short: new defects first, then any disputed severity resolved with evidence rather than opinion, then overdue items re-prioritised or escalated, then anything whose context has changed, then a sweep of aged low-priority tickets to close what will never be done. Weekly is right in steady state; daily in the last week before a release.
5. The two metrics worth watching
Defect escape rate is the share of defects that reached production out of all defects found: escapes divided by total defects, times one hundred. It is the honest score for a test process. Fix verification rate is the share of fixes that pass retest first time. A low escape rate with a poor verification rate means testing is fine and the fixes are rushed.
Both options we offer report on this scheme. See software testing and QA.
Quick checklist
- Keep severity (impact) and priority (schedule) in separate fields
- Define the four severity levels in writing and share them
- Let the finder set severity from evidence and the owner set priority
- Cap triage at four people and two minutes per defect
- Require a severity, a priority and a named owner before anything leaves triage
- Close aged low-priority tickets honestly instead of hoarding them
- Track defect escape rate and fix verification rate every quarter
Frequently asked
Who decides severity if we disagree?
The person who found the bug proposes it from evidence, and disputes are settled in triage by looking at impact, not by who is loudest. If a workaround exists and is practical, it is not critical.
Can a trivial bug ever be top priority?
Yes, and it happens often. A typo on the pricing page is trivial in severity and urgent in priority the week of a launch. That combination is exactly why the two fields are kept separate.
What is a good defect escape rate?
There is no universal number. What matters is your own trend: measure escapes divided by total defects found, watch it quarter by quarter, and set the target from the cost of a bug reaching your customers.