Beginner-Friendly Topic
Take your time - it's perfectly normal to re-read this topic 2-3 times. Try the interactive code editor below to run code yourself. Use the Q&A section to check your understanding before moving on. You've got this! 🚀
Severity vs Priority
Severity and Priority are two independent bug dimensions that are consistently confused - even by experienced testers. Getting this wrong causes the wrong bugs to be fixed first, critical user-facing issues to be delayed, and minor technical problems to block releases. This distinction is always tested in SDET interviews.
Definitions and Independence
- Severity: The TECHNICAL impact of the bug on the system. Measured by the QA team. Does not change based on business timing.
- Critical: System crash, data loss, security breach, complete feature failure
- Major: Core feature broken, significant incorrect behavior, performance severely degraded
- Minor: Feature partially works, workaround exists, non-critical feature affected
- Trivial: Cosmetic issues, typos, minor UI inconsistencies
- Priority: The BUSINESS URGENCY of fixing the bug. Measured by the Product/Business team. Changes based on deadlines, user impact, and timing.
- High Priority: Must be fixed immediately or in this sprint
- Medium Priority: Fix in next sprint or planned release
- Low Priority: Fix when bandwidth allows
The 4 Severity/Priority Combinations
// ══════════════════════════════════════════════════════════════
// CASE 1: High Severity + High Priority
// ══════════════════════════════════════════════════════════════
// Bug: Payment processing fails completely - users cannot checkout
// Severity: CRITICAL (complete feature failure, revenue impact)
// Priority: HIGH (must fix NOW - every hour costs money)
// Action: Developer drops current work and fixes immediately
// ══════════════════════════════════════════════════════════════
// CASE 2: High Severity + Low Priority
// ══════════════════════════════════════════════════════════════
// Bug: Admin panel crashes when viewing reports from 2019
// Severity: MAJOR (system crash = high technical severity)
// Priority: LOW (admin-only feature, 2019 data rarely accessed,
// no users impacted, fix it in backlog)
// Action: Logged, deferred to next quarter
// ══════════════════════════════════════════════════════════════
// CASE 3: Low Severity + High Priority
// ══════════════════════════════════════════════════════════════
// Bug: Company logo is misspelled "Googel" on the homepage
// Severity: TRIVIAL (cosmetic only, no functional impact)
// Priority: HIGH (tomorrow is a product launch and press coverage;
// the CEO personally flagged this)
// Action: Designer fixes tonight before launch
// ══════════════════════════════════════════════════════════════
// CASE 4: Low Severity + Low Priority
// ══════════════════════════════════════════════════════════════
// Bug: Footer text says "Copyright 2023" but it's 2026
// Severity: TRIVIAL (no functional or security impact)
// Priority: LOW (mentioned in sprint review, will fix when quiet)
// Action: Backlog, fix in quarterly housekeeping sprint
// ══════════════════════════════════════════════════════════════
// SDET Interview Question Answer Format:
// ══════════════════════════════════════════════════════════════
// "Severity is set by the testing team based on technical impact.
// Priority is set by the business/product team based on urgency.
// They are independent - a high-severity bug can be low priority
// if it affects an unused feature; a low-severity bug can be
// high priority if it affects brand appearance before a launch."Quick Quiz - Severity vs Priority
Common Mistakes
- Treating Severity = Priority - the most common mistake; a bug can be any combination of the two
- Letting developers set priority - priority is a business decision, not a technical one; developers should not override it
- Never using Trivial/Low severity - if every bug is Critical, the label loses meaning; calibrate correctly
- Changing severity based on timeline - severity is objective technical impact; it doesn't change because a deadline is approaching
Tip
Tip
Practice Severity vs Priority in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Testing pyramid: many unit tests, fewer integration, fewest E2E
Practice Task
Note
Practice Task - (1) Write a working example of Severity vs Priority from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Common Mistake
Warning
A common mistake with Severity vs Priority is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Severity and Priority are two independent bug dimensions that are consistently confused - even by experienced testers.
- Severity: The TECHNICAL impact of the bug on the system. Measured by the QA team. Does not change based on business timing.
- Critical: System crash, data loss, security breach, complete feature failure
- Major: Core feature broken, significant incorrect behavior, performance severely degraded