Leonardo_Phoenix_10_a_highcontrast_warmtoned_photograph_of_a_d_1

Defect Severity vs. Priority: Complete Guide with Real-World Examples

by
with 104 comments
Defect Severity vs. Priority

Understanding the difference between severity and priority is crucial for effective defect management. Let me break down both concepts with clear explanations and practical examples.

1. Defect Severity: “How Bad is the Bug?”

Definition:
Severity measures the technical impact of a defect on the system’s functionality.

Severity Levels:

LevelDescriptionReal-World Example
CriticalCauses system crash/data lossMyntra: Payment gateway failure causing order loss
MajorKey functionality brokenMyntra: “Add to Cart” button not working
MediumPartial functionality lossMyntra: Product filters not sorting correctly
MinorCosmetic/low-impact issuesMyntra: Misaligned footer text on mobile

Key Characteristics:

  • Determined by QA/testers during bug reporting
  • Based on technical impact only
  • Helps developers understand fix complexity

Real-World Scenario:
A “Critical” severity bug in Myntra where users’ shopping carts get emptied automatically would require immediate attention, even if it affects only 5% of users.

2. Defect Priority: “How Soon Should We Fix It?”

Definition:
Priority determines the urgency of fixing the defect based on business impact.

Priority Levels:

LevelDescriptionReal-World Example
P1 (High)Must fix in current releaseMyntra: Checkout failure during Big Billion Day sale
P2 (Medium)Fix in next regular releaseMyntra: Wishlist icon color inconsistency
P3 (Low)May fix in future releasesMyntra: Typo in FAQ section

Key Characteristics:

  • Decided by product managers/business
  • Based on user impact & business goals
  • Can change over time (e.g., before sales events)

Real-World Scenario:
A “P1” priority bug in Myntra where the “Apply Coupon” button fails during festival season sales, even though it’s only a “Medium” severity issue.

3. Severity vs Priority: Key Differences

FactorSeverityPriority
FocusTechnical impactBusiness impact
Decided ByQA TeamProduct/Business
Can Change?Rarely (unless misclassified)Frequently (based on timelines)
ExampleSystem crash (Critical)Logo typo before IPO (High)

Visual Analogy:
Severity = How sick is the patient? Priority = Which patient gets treated first in ER?

4. Real-World Combination Examples (Myntra Case Studies)

Case 1: High Severity + High Priority

  • Bug: Payment failure for all users
  • Severity: Critical (complete functionality break)
  • Priority: P1 (direct revenue impact)
  • Action: Hotfix deployed within hours

Case 2: High Severity + Low Priority

  • Bug: Search crashes when using Tamil language
  • Severity: Major (functionality broken)
  • Priority: P3 (only affects 0.1% user base)
  • Action: Scheduled for next quarterly release

Case 3: Low Severity + High Priority

  • Bug: “25% Off” banner shows “52% Off” during Diwali sale
  • Severity: Minor (cosmetic)
  • Priority: P1 (legal/false advertising risk)
  • Action: Fixed within 1 business day

5. Best Practices for Classification

  1. QA Team Should:
  • Assign severity objectively
  • Provide clear reproduction steps
  • Suggest priority (but final call by PM)
  1. Product Managers Should:
  • Consider business timelines
  • Evaluate user impact
  • Reassess priorities regularly
  1. Developers Should:
  • Respect priority order
  • Verify severity during fix
  • Communicate timeline impacts

6. Common Mistakes to Avoid

Mistake: Assuming high severity = high priority
Solution: Some critical bugs may affect few users (e.g., Edge browser crash)

Mistake: Setting all UI bugs as low severity
Solution: Brand-damaging UI issues can be high priority

Mistake: Not reviewing priorities before releases
Solution: Conduct priority triage meetings weekly

7. Defect Triage Process Example

Myntra’s Weekly Bug Review Meeting:

  1. QA presents new defects with severity
  2. Product reviews business impact
  3. Tech lead assesses fix complexity
  4. Final priority assigned (P1/P2/P3)
  5. Added to sprint planning accordingly

Sample Output:
“Search crash in Tamil (Major Severity) marked P2 – will fix in v2.3 after current sale”

8. Tools for Tracking

  • JIRA: Set both severity (labels) and priority (field)
  • Bugzilla: severity/priority dropdowns
  • Excel Trackers: Color-code by severity/priority

Pro Tip:
“Tag P1 bugs with emoji in Slack alerts for immediate visibility”

Conclusion

Mastering severity vs priority helps:

  • QA teams communicate technical impact effectively
  • Business teams make informed scheduling decisions
  • Dev teams focus on what matters most

Golden Rule:
“Severity tells you how deep the water is, priority tells you who’s drowning first.”

104 Responses

  1. VAedriaae

    – Мне не нужно знать, – придушенным, злым голосом отозвался Пилат, – приятно или неприятно тебе говорить правду. самостоятельная раскрутка сайтов – «Молодец!» Или: «Пойти к Берлиозу, он сегодня от четырех до пяти принимает в Грибоедове…» и так далее.

Add a Comment

Your email address will not be published. Required fields are marked *