Defect Severity vs Priority

Severity and Priority are two different ways of evaluating a defect. Understanding the difference helps teams decide both how much the defect impacts the system and how urgently it should be fixed.

What Is Defect Severity?

Severity describes the impact of a defect on the functionality or operation of the software.

It answers:

“How badly does this defect affect the system?”

Common severity levels include:

1. Critical

   • Causes complete system failure or affects a critical business function.

   • Example: Users cannot log in to the banking application.

2. High

   • Major functionality is significantly affected, but the entire system may still be usable.

   • Example: Customers cannot complete a payment.

3. Medium

   • A feature is affected, but a workaround may be available.

   • Example: Users cannot download a report, but they can view it online.

4. Low

   • Minor functional or visual impact.

   • Example: A small alignment issue on a non-critical page.

What Is Defect Priority?

Priority describes how urgently the defect should be fixed from a business or release perspective.

It answers:

“How soon should this defect be fixed?”

Common priority levels include:

1. High

   • Should be fixed as soon as possible.

   • Usually affects critical functionality, customers, revenue, security, or a release deadline.

2. Medium

   • Should be fixed, but it may not need immediate attention.

3. Low

   • Can be addressed later when higher-priority work is completed.

Severity vs Priority

Think of the difference as:

• Severity = Impact

• Priority = Urgency

A defect can have high severity but low priority, or low severity but high priority, depending on the situation.

Examples

Example 1: High Severity + High Priority

A payment system crashes when customers try to complete a purchase.

• Severity: High

• Priority: High

• Reason: Major functionality is broken and directly affects revenue.

Example 2: Low Severity + High Priority

A company's official website has a spelling mistake in a highly visible homepage banner during a major marketing campaign.

• Severity: Low

• Priority: High

• Reason: The functional impact is small, but the business and brand impact makes the fix urgent.

Example 3: High Severity + Low Priority

A rarely used administrative report causes an application error, but the feature is not currently needed for the release.

• Severity: High

• Priority: Low

• Reason: The functionality is seriously affected, but there is little immediate business urgency.

Example 4: Low Severity + Low Priority

A minor spacing issue appears on an internal settings page.

• Severity: Low

• Priority: Low

How to Decide Severity

Consider:

• How much functionality is affected?

• Is the system or feature unusable?

• Does it affect critical business operations?

• Is there a workaround?

• How many users are affected?

• Does it cause data loss or corruption?

• Does it create a security or financial risk?

How to Decide Priority

Consider:

• Is the defect blocking a release?

• Does it affect customers or revenue?

• Is it affecting a critical business workflow?

• Is there a deadline?

• Is the affected feature highly visible?

• Is there a regulatory, contractual, or business requirement?

• Are many users affected?