Lesson 2 of 5
Severity, priority and business impact
8 min
Listen to this lesson
Two fields drive what happens to a defect next, and they are often confused. Severity describes the degree of impact the defect has on the system or process. Priority describes how urgently it should be fixed, relative to everything else. They usually move together, but not always, and the cases where they differ are exactly where good judgment matters.
A severity rubric
| Severity | Definition | Contoso example |
|---|---|---|
| Critical | A core process cannot be completed, data is corrupted, or a legal or financial obligation is broken; no workaround | Goods issue fails for every delivery from plant 1710 |
| High | A core process fails or produces wrong financial results; a workaround exists but is costly or risky | Fleet invoices post revenue to the wrong account; manual reclassification possible |
| Medium | A process works with a reasonable workaround, or a non-core function fails | A Fiori list filter for open deliveries ignores the shipping point |
| Low | Cosmetic or minor issue with no effect on results | A spelling mistake in a field label on an internal screen |
An example rubric. Your program's test strategy defines the official one; use it consistently.
Priority reflects business urgency
Priority asks: given our plan, when must this be fixed? It depends on the date, the business calendar and who is affected. A spelling error on the customer invoice layout is low severity (no wrong numbers), but if it is found two days before go-live it may be high priority, because every customer will see it on the first invoice. A high-severity defect in a process that is not used until year-end close may have lower priority than a medium one blocking next week's UAT.
Who sets what
A common and workable split: the tester proposes severity from the rubric when logging, because the tester saw the impact. Priority is set or confirmed in triage by the test lead with the process owner and the fixing team, because it weighs business urgency against capacity. At Contoso, Priya chairs triage; Dan decides priority for finance defects and Maria's process owner for order to cash.
- Tester logsProposes severity from the rubric, with business impact described
- TriagePriya validates the defect and checks the severity
- Process ownerDan for finance or Maria's process owner for order to cash confirms priority
- AssignedThe fixing team receives it with an agreed urgency
- ReviewedSeverity and priority revisited on each triage cycle as the calendar moves
Severity and priority should both be revisited as the program moves. A medium defect in a report used only by planners might be low priority in integration testing and high priority the week before planners start UAT. Triage reviews open defects on a regular cycle precisely so priorities follow the calendar, rather than staying frozen at the values set on the day each defect was logged.
Think business impact, not screen impact
SAP defects can look small on screen and be large in effect. A tax code defaulting wrongly for shipments from plant 1720 shows as one field. Its business impact is under-collected sales tax on every Chicago shipment. When you set severity, describe the impact in money, stock, customers, compliance or people, and the rubric becomes much easier to apply honestly.
Workarounds deserve care. A workaround lowers severity only if it is realistic for the people who will use it, at the volumes they will see. Reclassifying revenue manually for five test invoices is easy; doing it for every fleet invoice in a month is a control risk and a finance team's overtime. Record the workaround in the defect and ask the process owner whether it is acceptable before using it to downgrade.
- Is there a workaround at all?Yes → go on · No → severity stays as the rubric says
- Is it realistic for the real users at real volumes?Yes → go on · No → do not downgrade; five test invoices are not a month of fleet billing
- Has the process owner accepted it, and is it recorded on the defect?Yes → severity may be lowered · No → keep severity until they do
What would you do?
Two days before Contoso's go-live, Maria finds that the customer invoice form prints "Allternator" in the product description line. Totals, tax and posting are all correct. How should the defect be classified?
- Severity is impact; priority is urgency. They are separate fields.
- Use a written rubric for severity and apply it strictly.
- Testers propose severity; triage with the process owner confirms priority.
- Describe impact in business terms; check workarounds are realistic before downgrading.
Check your understanding · not graded
Lesson check
1. A spelling error on the customer invoice layout is found two days before go-live. Which classification is most reasonable?
2. What does severity describe?
3. Who typically confirms a defect's priority?
4. When can a workaround justify lowering severity?