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:
| Level | Description | Real-World Example |
|---|---|---|
| Critical | Causes system crash/data loss | Myntra: Payment gateway failure causing order loss |
| Major | Key functionality broken | Myntra: “Add to Cart” button not working |
| Medium | Partial functionality loss | Myntra: Product filters not sorting correctly |
| Minor | Cosmetic/low-impact issues | Myntra: 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:
| Level | Description | Real-World Example |
|---|---|---|
| P1 (High) | Must fix in current release | Myntra: Checkout failure during Big Billion Day sale |
| P2 (Medium) | Fix in next regular release | Myntra: Wishlist icon color inconsistency |
| P3 (Low) | May fix in future releases | Myntra: 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
| Factor | Severity | Priority |
|---|---|---|
| Focus | Technical impact | Business impact |
| Decided By | QA Team | Product/Business |
| Can Change? | Rarely (unless misclassified) | Frequently (based on timelines) |
| Example | System 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
- QA Team Should:
- Assign severity objectively
- Provide clear reproduction steps
- Suggest priority (but final call by PM)
- Product Managers Should:
- Consider business timelines
- Evaluate user impact
- Reassess priorities regularly
- 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:
- QA presents new defects with severity
- Product reviews business impact
- Tech lead assesses fix complexity
- Final priority assigned (P1/P2/P3)
- 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.”