Manual Testing interview question
What is the difference between severity and priority? Give examples.
Short answer
Severity is the technical impact of a defect on the system; priority is how urgently the business needs it fixed. They are set by different people for different reasons, so they can diverge: a typo in the company name on the home page is low severity but high priority.
Answer
Severity describes how much damage a defect does to the system: data loss, a crash, a blocked workflow, or a cosmetic glitch. Priority describes how soon the business wants it fixed relative to everything else. Severity is mostly a technical judgement, usually proposed by the tester; priority is a business decision, usually set by the product owner or in a triage meeting. Because they answer different questions, they do not always move together.
Typical scales
Most teams use something like:
| Severity | Meaning |
|---|---|
| Critical / Blocker | Crash, data loss, security hole, no workaround, core flow blocked |
| Major | Important feature broken, workaround is painful |
| Minor | Feature works but incorrectly in a limited way, easy workaround |
| Trivial / Cosmetic | Visual or text issue with no functional effect |
Priority is often P1 (fix now / hotfix), P2 (fix this sprint or release), P3 (fix when convenient), P4 (backlog). The exact labels vary by tool (Jira ships with Highest to Lowest), so mention that your team’s definitions are what matter.
The four combinations
- High severity, high priority: checkout returns a 500 for every card payment. Revenue is blocked, fix immediately.
- High severity, low priority: the app crashes when exporting a report with more than 10,000 rows in a legacy browser that very few customers still use, and there is a documented workaround. Severe when it happens, but the business may schedule it later.
- Low severity, high priority: the company name is misspelled in the home page header, or the wrong logo appears the day before a launch. Nothing is functionally broken, but the brand and legal impact make it urgent.
- Low severity, low priority: a misaligned icon on an internal admin settings page.
Why the distinction matters
If testers only report severity, the team cannot plan; if product only reports priority, the team loses the technical signal (a “low priority” crash may still indicate a deeper data integrity problem). Keeping both lets triage make an informed trade-off and lets you track, for example, how many critical defects escaped to production regardless of how they were prioritised.
Priority also changes over time. A minor bug in a feature that is about to be demoed to a large customer can jump to P1 for a week. Severity normally does not change unless new information reveals more impact.
What interviewers look for
- Clear, one-sentence definitions that separate technical impact from business urgency.
- Concrete examples for the “mismatched” combinations, not just high/high.
- Awareness that the tester proposes severity but priority is negotiated with product.
- Recognition that scales and labels are team-specific.
Common mistakes
- Treating the two as synonyms or saying “priority is decided by severity”.
- Inflating severity to get a bug fixed faster. That erodes trust in your reports; argue priority with business impact instead.
- Giving only the textbook “logo” example without explaining why it is urgent.
A strong answer covers
- Defines severity as technical or functional impact
- Defines priority as business urgency or order of fixing
- Gives a high-priority, low-severity example
- Gives a high-severity, low-priority example
- Says who usually sets each one