Priority Vs Severity - A Beginners Guide

#testing #agile #software #development

In software testing and bug tracking, two concepts are common; priority and severity; both are used to describe a bug/defect. However, they are also often confusing. In this guide, we get to differentiate these two.

Severity - It answers the question "How bad (technically) does a defect affects software or a functionality?" QA Engineers or testers determine the severity of a defect. For example, a defect blocking testing would be termed as a high severity.

Priority - Think of it as "How urgently do we need to fix this defect?" Priority is usually set by the business team or product owner based on business and customer needs.

Both severity and priority are typically categorized into different levels to help teams assess and manage defects effectively. The exact number of levels may vary across organizations and projects, but the underlying principle remains the same: severity measures the technical impact of a defect, while priority determines the urgency with which it should be addressed.
Understanding these levels helps teams make informed decisions about bug triaging, resource allocation, and release planning.

Severity

Severity can be categorized into 4 different levels;

S1(Critical) - System crash or complete failure; further testing cannot continue. No workaround.
Example - App crashes on launch for all iPhone 17 devices.
S2(Major) - A major feature fails, but the rest of the application remains usable. But a workaround exists.
Example - Checkout fails on Pixel 8 but works on other Android devices
S3(Minor) - A functional issue with a temporary workaround available.
Example - Push notification shows wrong order status but tapping it opens correct screen
S4(Low) - A minor issue with little or no impact on functionality.
Examples
- Button padding is 2px off on settings screen
- Date format shows MM/DD/YYYY instead of DD/MM/YYYY for UK locale Each of these levels differs on the technical damage to the application with S1 being critical and S4 being a low.

Priority
Priority is also classified into 4 different levels;

P1(Immediate) - Must be fixed immediately halting other development work as it affects user experience and business functionality.
Example - Payment processing fails for all users after a backend deploy
P2(High) - It must be fixed soon, typically within the current sprint or release cycle
Example - Onboarding flow broken on iOS 18 (30% of user base)
P3(Medium) - Should be fixed during the normal development cycle.
Example - Search filters reset when rotating device
P4(Low) - Can be fixed in a future release with minimal business impact
Example - Help section links open in external browser instead of in-app WebView

Each of this levels differs on the time; how fast do we need to fix the defect; with a P1 indicating need for instant action, while a P4 can wait or be put on hold.

`
The severity of bug classification doesn't change based on business context. A crash is a crash whether it happens during a product launch or a quiet Tuesday. Severity is objective and technical. Your bug severity definitions and bug priority definitions should be documented so whole team applies them consistently.

Priority can change. A P3 bug becomes P1 if a major client reports it. A P1 bug becomes P3 if a hotfix ships a workaround. Bug severity stays constant. Bug priority shifts with business context.
`

From the 4 categories of each of the two parameters, we can come up with a decision matrix. This should help with decisions on resource allocation and release planning.

Real-World Examples

From the decision matrix above, there are often four common combinations.

High Severity / High Priority

Example: The system crashes completely when a user clicks the checkout button, blocking all sales.

The product functionality is completely broken (High Severity)
The company is actively losing revenue (High Priority).

High Severity / Low Priority

Example: The application crashes, but only when run on an outdated legacy operating system that less than 0.1% of users use.

A system crash is technically critical (High Severity)
However, it has negligible impact on the overall customer base, only 0.1% of users are affected(Low Priority).

Other Examples

A crash that only happens on a rare device
App crashes when entering 500+ characters in a search field no user would fill

Low Severity / High Priority

Example: The company name or logo is misspelled on the homepage e.g. "Amaozn" instead of "Amazon"

A text typo does not break any system code or backend functionality (Low Severity)
However, it heavily damages brand reputation and must be resolved immediately (High Priority).

Low Severity / Low Priority

Example: A minor visual spacing issue or slight color misalignment occurs on a sub-page deep within the settings menu.