Severity vs Priority Classification
Every QA job interview includes some variant of 'explain the difference between severity and priority.' More importantly, misclassifying these leads to incorrect resource allocation and poor release decisions. Severity measures the technical impact on the system; Priority measures the business urgency of fixing it. They are independent - it's completely valid to have a high-severity, low-priority defect or vice versa.
Defining Severity - Technical Impact
- Critical: System is completely unusable or data loss/corruption is occurring. Examples: application crashes on login for all users, payment transactions being double-charged, personal data exposed to unauthorized users. No workaround exists. Testing should be suspended for the affected area until fixed
- High: A major feature or function is not working correctly. Significant impact on user workflow but the system remains partially functional. Examples: search returns no results, checkout fails for specific payment methods. Workaround may exist but is unacceptable long-term
- Medium: A feature is working but not correctly in specific scenarios. Impact is noticeable but doesn't prevent core workflows. Examples: data in table not sorting correctly, email notification sent with wrong timestamp, minor calculation error in non-critical field
- Low: Minor cosmetic or aesthetic issues with no functional impact. Examples: typo in a tooltip, misaligned UI element, incorrect color in a secondary button
Defining Priority - Business Urgency
Priority is a BUSINESS decision, not a technical one. It tells the development team how urgently to fix the defect relative to other work. High Priority: Must be fixed before release, even if workaround exists - the business impact of releasing with this defect is unacceptable (reputational, legal, financial). Medium Priority: Should be fixed in this release if possible; if not, can be deferred with documented risk. Low Priority: Can be deferred to a future release without significant business impact. Classic examples of mismatched Severity vs Priority: Broken logo on homepage (Low Severity, High Priority - CEO is presenting from this page tomorrow). Admin panel calculation error (Medium Severity, Low Priority - only 2 admin users, workaround is manual calculation). This distinction is critical at release decisions - a Critical-severity defect might be Low-priority if it only affects an internal debugging screen used by 2 engineers.
Playwright rising fast - modern API, auto-waits, all browsers
Tip
Tip
Practice Severity vs Priority Classification in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Severity vs Priority Classification 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.
Quick Quiz
Common Mistake
Warning
A common mistake with Severity vs Priority Classification is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- Every QA job interview includes some variant of 'explain the difference between severity and priority.
- Critical: System is completely unusable or data loss/corruption is occurring. Examples: application crashes on login for all users, payment transactions being double-charged, personal data exposed to unauthorized users. No workaround exists. Testing should be suspended for the affected area until fixed
- High: A major feature or function is not working correctly. Significant impact on user workflow but the system remains partially functional. Examples: search returns no results, checkout fails for specific payment methods. Workaround may exist but is unacceptable long-term
- Medium: A feature is working but not correctly in specific scenarios. Impact is noticeable but doesn't prevent core workflows. Examples: data in table not sorting correctly, email notification sent with wrong timestamp, minor calculation error in non-critical field