Key takeaways
- Severity is about impact; priority is about urgency.
- Testers propose severity; business and team decide priority.
- Define levels and examples in writing so ratings stay consistent.
- Triage meetings review new defects and assign owners.
- Re-rate when new information appears, such as more affected users.
What is defect severity and priority?
Why are two ratings needed?
A single rating mixes two questions. "How bad is this?" depends on the failure itself. "How soon must we fix it?" depends on release dates, customer commitments, workarounds and effort. Keeping them apart avoids arguments and helps teams plan fixes in a sensible order.
What are common severity levels?
| Level | Meaning | Example |
|---|---|---|
| Critical | System unusable, data loss or security breach | App crashes on login; payments charged twice |
| High | Major feature broken, no workaround | Cannot add items to cart |
| Medium | Feature partly affected, workaround exists | Filter returns wrong results but search works |
| Low | Minor or cosmetic | Misaligned label |
| Teams may use different names, so write down your own definitions and examples. |
What are common priority levels?
Urgent or P1: fix immediately, may block release. High or P2: fix in the current cycle. Medium or P3: schedule for a later cycle. Low or P4: fix if time allows. Priority can change when business context changes.
How do the two combine?
| Case | Severity | Priority |
|---|---|---|
| Crash on a rarely used admin screen | High | Low |
| Company name misspelled on home page before launch | Low | High |
| Checkout fails for all customers | Critical | Urgent |
| Slight colour mismatch in footer | Low | Low |
| These four patterns appear in interviews and are worth remembering with their reasons. |
Who decides?
The tester reports the defect and suggests severity based on observed impact. The product owner, project manager or a triage group sets priority, considering how many users are affected, revenue or legal exposure, contractual dates and the effort to fix. The developer adds an estimate. Agreement is reached in conversation, not by editing fields back and forth.
What happens in triage?
A triage meeting, often short and regular, reviews new defects. For each: confirm it is reproducible and not a duplicate, check severity, set priority, assign an owner and decide the target release. Reject invalid items with a reason. Keep the meeting focused with a prepared list and clear criteria.
How do I avoid disputes?
Agree on definitions before testing begins and keep examples in the test plan. Write defect titles and descriptions with facts and impact, not opinions. Include affected users, frequency and any workaround. When a developer disagrees, discuss the evidence and agree on what extra information would settle it.
What extra attributes help?
Frequency of occurrence, affected platforms, regression flag, customer reported flag and environment. These help decide priority and show patterns, such as modules that produce many high-severity defects.
What mistakes are common?
Marking everything high to get attention, using priority as a mood, never revisiting ratings, mixing severity with effort and arguing in comments instead of talking. Honest ratings preserve trust.
How do I explain this in an interview?
Start with a one-line definition of each term, give the two classic examples with reasons and mention who decides. For instance: "Severity is the technical impact and priority is the urgency. A crash on a rarely visited admin page is high severity and low priority, while a spelling error in the company name on the launch page is low severity and high priority. The tester proposes severity and the product owner sets priority." This answer is short, correct and shows practical understanding.
How do ratings connect to release decisions?
Release criteria often state that no critical or high-priority defects remain open, and that medium defects have a plan. Test reports summarise open defects by severity and priority so stakeholders can decide whether to release. Accurate ratings therefore matter beyond the defect tool: they affect go or no-go decisions, customer trust and the work of the whole team, so take the time to rate carefully and explain your reasoning.
What is a template for rating a defect?
Write: "Impact: who is affected and how. Frequency: how often. Workaround: yes or no. Suggested severity: level. Reason: one sentence." Using the same template for every defect makes triage faster and fairer, and new team members learn the standard quickly by reading past entries.
How do I handle a disagreement politely?
Ask what information would change the rating, gather it together and agree on a rule for similar cases so the debate does not repeat.
What is a one-line summary to remember?
Severity measures how bad the failure is for the product; priority measures how soon the business needs the fix, and they can differ.
Download Defect Severity and Priority Guide PDF
Defect Severity and Priority Guide PDF
The PDF carries the same content as this page in a clean, print-ready layout, so you can read it offline and keep it for revision.
4 pages · 91 KB · PDF · Updated 5 Nov 2026