Defect Severity and Priority: Types, Levels, and Examples

In this tutorial, you will learn about Defect Severity and Priority in Software Testing and how to prioritize and classify severity of the defect in example-based scenarios to understand the concept.

Defects priority and severity are not the same in software testing. Although the defect severity aids testing professionals in determining the severity of the defect in the system, the defect priority aids in deciding the criticality of fixing the issue.

It is essential to understand the concept of defect severity and priority in order to report the defects accurately.

This article provides information on defect severity, defect severity levels, examples, and difference between defect severity and priority.

Filing defects is a very integral part of the Software Testing Life Cycle. Several best practices are defined for effective Defect Reporting over the internet or in organizations.

Defect Tracking and Defect Classification

Defect tracking is an important part of the software defect life cycle. During testing, teams may identify and report numerous defects, particularly when working with complex applications. Properly recording, categorizing, and tracking these defects helps teams prioritize fixes and manage them through to closure.

When a tester reports a defect, the report typically includes details such as steps to reproduce the issue, its expected and actual behavior, and classification information.

Defect severity and priority are two important parameters used to classify and manage reported defects.

Severity and priority are sometimes used interchangeably, but they represent different aspects of a defect. Severity describes the impact a defect has on the application, while priority indicates how urgently it should be fixed. Understanding this distinction helps QA teams and stakeholders make better decisions during defect triage and resolution.

The next section explains defect severity and priority in detail.

What Is Defect Severity in Software Testing?

Defect Severity is an estimation of the technical damage caused by the defect to the functionality, stability, or operations of the software being developed. This is a measure of the technical impact of the defect, which is not related to deadlines or any timeline of the project. The severity is classified as Critical, Major, Minor, and Low/Trivial. The severity levels may differ from company to company.

Simply put, severity is a measure of the impact of the defect, whereas priority is its urgency for fixing.

Purpose of Defect Severity

• Determine Technical Impact: To help developers assess the technical problems, data loss, and functional failure.
• Test Execution Prioritization: To help testers limit testing efforts on a certain build, in case there are defects that block testing efforts.
• Objective Criterion for Defect Triage: To provide a team member with the technical criteria for assessing defects before prioritizing them during triage.

Who Assigns Defect Severity?

• Software Test Engineer/QA Analyst: This is the main assignment role where the tester evaluates the technical impact by comparing it with the functional specifications.
• Lead Tester/QA Manager: This is the role which can change the severity rating at triage, in case there is an under/over estimation of the technical impact.
• Developers/Technical Leads: This is the role whose advice may be asked in case root cause analysis has identified that system components have been affected beyond visual.

The below figure depicts the role of who owns & classifies the criticality & severity of the defects.

Defect Severity Levels

Defect severity level classification considers the technical implications of the defect on the functionality of the software, stability of it, and data integrity. The classification is aimed at ensuring that both development and testing teams have the same understanding of the system impact.

Severity Level	Code	Impact Summary	Immediate Workaround?
Critical Severity	S1	Total feature failure, system crash, or data corruption.	No
Major Severity	S2	Core function broken or severely degraded.	Yes (Complex / Partial)
Minor Severity	S3	Non-critical feature failure or secondary utility issue.	Yes (Simple UI/Path)
Low / Trivial Severity	S4	Cosmetic defect, minor typo, or visual misalignment.	N/A (Does not block function)

Critical Severity (S1)

The critical severity bug means that there is either a total failure, a system crash, or a security/data loss condition on the key user paths with no workaround available. Testing or using of the particular module is entirely blocked.

Examples:

• Databases Corrupted: While saving the changes made to the user profile, the existing tables for the users in the database are lost.
• Authentication Bug: The main SSO/auth portal returns 500 error code for all the users trying to access the app.
• Crashing Payment Processing: The checkout feature crashes the application server during payment transactions.

Major Severity (S2)

A Major Severity bug is present when there is a malfunction of some core feature/ability of the application in accordance with functional requirements, while the application is fully operable and there is an alternative workaround possible.

Examples :

• Export Bug: The bulk export functionality produces a timeout error when producing CSV files, while viewing and copying records manually from the UI is still possible.
• Filtering Products Bug: Filtering products by the price range produces wrong results, while searching for products by keywords or categories works just fine.
• Broken Secondary Path: It is impossible to reset the user password using the SMS link, while resetting a password by email works properly.

S3 – Minor Severity

The Minor Severity defect encompasses non-core functionalities or features, auxiliary functions, or logical errors that hinder the user experience or secondary functionalities but do not impede the execution of key business processes.

Examples:

• Sorting Issue: Table column sorting is set to descending order on initial click.
• Incorrect Tooltip Configuration: Mouseover dynamic dashboard icons display static text instead of the field metric values.
• Session Timeout: User session automatically logs out after 30 minutes of inactivity, even though the policy setting states 15 minutes.

S4 – Low or Trivial Severity

A Low or Trivial Severity defect refers to purely cosmetic issues, typographical errors in text, or discrepancies in layouts that have no effect on the operation of functional execution, data processing, or application logic.

Examples:

• Typo in Text in UI: Confirmation box has the message “Sucessfully saved” instead of “Successfully saved.”
• Button Layout: The ‘Cancel’ button in a modal is 4 pixels away from the main call-to-action button.
• Color Palette: Hex code #333333 is used for hover state of a component, while the correct color from the design system should be used.

Defect Severity Examples (functional and non-functional issues)

The following practical matrix illustrates how different functional and non-functional issues across an application are classified into their corresponding severity levels:

Defect Scenario	Affected Module	Observed Behavior	Assigned Severity
Main database connection closes permanently on concurrent user load	Core Infrastructure	Application renders a blank page for all users; requires manual server restart	Critical (S1)
E-commerce cart total miscalculates discount logic	Order Management	Cart applies a 20% coupon code to excluded clearance items	Major (S2)
Date picker component fails on leap years	Forms / Booking	Form validation fails only when selecting February 29th	Major (S2)
User avatar upload accepts unsupported PNG dimensions	User Profile	Profile image scales incorrectly and distorts aspect ratio on dashboard view	Minor (S3)
Breadcrumb link navigation misses hover state animation	UI / Frontend	Clicking breadcrumb works correctly, but CSS transition fails to highlight text	Low / Trivial (S4)
Footer copyright year displays past year	Layout Footer	Copyright text displays previous calendar year	Low / Trivial (S4)

What Is Priority

Priority, as the name suggests, is about prioritizing a defect based on business needs and the severity of the defect. Priority signifies the importance or urgency of fixing a defect.

While opening a defect, the tester assigns the priority initially as he views the product from the end-user perspective. In line with these, there are different levels:

Broadly, the Priority of the defects can be classified:

Priority #1: Immediate/Critical (P1)

This has to be fixed immediately within 24 hours. This occurs when an entire functionality is blocked and no testing can proceed because of this. In certain other cases, if there are significant memory leaks, then the defect is classified as a priority -1, meaning the program/ feature is unusable in the current state.

The immediate category will be assigned to any defect that needs immediate attention and affects the testing process.

All the Critical severity defects fall under this category (unless re-prioritized by business/stakeholders)

Priority #2: High (P2)

Once the critical defects have been fixed, a defect having this priority is the next candidate, which has to be fixed for any test activity to match the “exit” criteria.

Normally when a feature is not usable as it’s supposed to be, due to a program defect, or that new code has to be written, or sometimes even because some environmental problem has to be handled through the code, a defect may qualify for a priority 2.

This is the defect, or issue, which should be resolved before the release is made. Let’s resolve these defects once we address the Critical issues.

All the Major severity defects fall into this category.

Priority #3: Medium (P3)

A defect with this priority must be in contention to be fixed, as it could also deal with functionality issues that are not as per expectation. Sometimes even cosmetic errors, such as expecting the right error message during the failure, could qualify to be a priority 3 defect.

This defect should be resolved after all the serious bugs are fixed.

Once the Critical and the High-priority bugs are done, we can go for the medium-priority bugs.

All the Minor severity defects fall into this category.

Priority #4: Low (P4)

A defect with low priority indicates that there is an issue, but it doesn’t have to be fixed to match the “exit” criteria. However, this must be fixed before the GA is done. Typically, some typing errors or even cosmetic errors, as discussed previously, could be categorized here.

Sometimes defects with priority low are also opened to suggest some enhancements in the existing design or a request to implement a small feature to enhance user experience.

This defect can be resolved and does not need any immediate attention and the Low severity defects fall into this category.

As already discussed, priority determines how quickly the defect turnaround time must be. If there are multiple defects, the priority decides which defect has to be fixed and verified immediately versus which defect can be fixed a bit later.

Difference Between Severity And Priority

Priority is associated with scheduling, and “severity” is associated with standards.

“Priority” means something is afforded or deserves prior attention; order of importance (or urgency establishes precedence).

“Severity” is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles. For Example, a severe code of behavior.

The words priority and severity come up in bug tracking.

A variety of commercial, problem-tracking/management software tools is available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its ‘Severity’, reproduce it, and fix it.

The fixes are based on the project ‘Priorities’ and ‘Severity’ of bugs.

The ‘Severity’ of a problem is defined following the customer’s risk assessment and recorded in their selected tracking tool.

Buggy software can ‘severely’ affect schedules, which can lead to a reassessment and renegotiation of ‘priorities’.

Defect Severity evaluates technical impact on system functionality, while Priority dictates business urgency for fixing the bug. The following comparison illustrates the difference in detail.

Comparison Parameter	Defect Severity	Defect Priority
Core Definition	Extent of technical impact on application stability, code integrity, or functionality.	Order of urgency in which the developer team must resolve the bug.
Primary Focus	Technical / Functional (How severely is the system broken?)	Business / Scheduling (How quickly must this be fixed?)
Assigned By	Software Test Engineer / QA Analyst	Project Manager / Product Owner / Business Analyst
Basis of Assessment	Functional specs, system architecture, data flow, and error complexity.	Release deadlines, user impact, client SLAs, and branding considerations.
Change Frequency	Objective & Static: Typically remains fixed unless technical root-cause analysis changes.	Subjective & Dynamic: Fluctuates based on project constraints, release cycles, or business goals.
Classification Levels	Critical (S1), Major (S2), Minor (S3), Low/Trivial (S4)	High (P1), Medium (P2), Low (P3)
Key Question Asked	“How badly does this issue break the system?”	“When do we need to deploy the fix?”

The following diagram illustrates the difference between priority and severity:

To summarize, the following figure depicts the broad Defect classification based on Severity and Priority:

Severity vs. Priority Matrix

Combination	Scenario Description
High Severity + High Priority	The primary payment gateway crashes on checkout during a live production release.
High Severity + Low Priority	A memory leak causes legacy background data export to crash, but the legacy module is scheduled for deprecation next month and affects 0.01% of users.
Low Severity + High Priority	The company logo on the public login page is pixelated or misspelled right before a major media press conference.
Low Severity + Low Priority	A hover animation on a secondary footer button takes 300ms instead of 150ms to transition.

Examples

As already mentioned, since different organizations use different tools for defect tracking and its related processes, it becomes a common tracking system between various levels of management and technical personnel.

Since Defect Severity is more within the purview of the functionality, the Test Engineer sets the severity of the defect. The developers take part in influencing the defect severity, but mostly it depends on the tester as he evaluates how much a particular feature can impact the overall functioning.

On the other hand, when it comes to setting defect priority, although initially, the defect originator sets the priority, it is defined by the Product Manager as having an overall view of the product and how quickly a particular defect has to be addressed. A tester is not an ideal person to set the defect priority.

Shocking as this may seem, there are two distinct examples as to why:

Example #1: Consider that there is a situation where the user finds a mistake in the product’s naming itself or some problem with the UI documentation. A tester would normally open a minor/cosmetic defect and may be very simple to fix, but when it comes to the product’s look and feel/user experience, it could cause a serious impact.

Example #2: There could be certain conditions under which a particular defect occurs which may be an extremely rare or no possibility to hit in the customer environment. Even though functionality-wise this may seem like a high-priority defect to a tester, considering its rarity of occurrence and high cost to fix – this would be classified as a low-priority defect.

Hence, in effect, the defect priority is generally set by the product manager in a “defect triage” meeting.

Severity vs. Priority Matrix Explained

Priority and Severity have some classifications that aid in determining how the defect must be handled. A lot of different organizations have different defect logging tools, so the levels might vary.

Let’s look at the different levels for both Priority and Severity.

• High Priority, High Severity
• High Priority, Low Severity
• High Severity, Low Priority
• Low Severity, Low Priority

The following figure depicts the classification of the categories in a single snippet.

#1) High Severity and High Priority

Any Critical/major business case failure automatically gets promoted to this category.

Any defects due to which the testing cannot continue at any cost or cause a severe system failure fall into this category. For example, clicking on a particular button doesn’t load the feature itself. Or performing a particular function brings down the server consistently and causes data loss. The red lines in the above figure indicate these kinds of defects.

For example, the system crashes after you make the payment or when you cannot add the items to the cart. This defect is marked as a High Severity and High Priority defect.

Another example would be the ATM vending currency feature wherein after entering the correct username and the password, the machine does not dispense money but deducts the transferred from your account.

#2) High Priority and Low Severity

Any minor severity defects that could directly impact the user experience automatically get promoted to this category.

Defects that have to be fixed but do not affect the application come under this category.

For example, the feature is expected to display a particular error to the user concerning its return code. In this case, functionally the code will throw an error, but the message will need to be more relevant to the return code generated. The blue lines in the figure indicate these kinds of defects.

For example, the logo of the company on the front page is wrong, it is considered to be High Priority and Low Severity defect.

Example #1: In the Online shopping website when the FrontPage logo is spelled wrong. For example, instead of Flipkart it is spelled as Flipkart.

Example #2: In the bank logo, instead of ICICI, it is written as ICCCI.

In terms of functionality, it is not affecting anything so we can mark as Low Severity, but it has an impact on user experience. This kind of defect needs to be fixed on high priority even though they have very little impact on the application side.

#3) High Severity and Low Priority

Any defect that is functionally not meeting the requirements or has any functional implications on the system but is sidelined to the back seat by the stakeholders for business criticality automatically gets promoted to this category.

Defects that have to be fixed but not immediately. This can specifically occur during ad hoc testing. It means that the functionality is affected to a large extent, but is observed only when certain uncommon input parameters are used.

For example, a particular functionality can be used only on a later version of the firmware, so to verify this – the tester downgrades his system and performs the test, and observes a serious functionality issue that is valid.

In such a case, the defects will be classified in this category denoted by pink lines, as normally end users will be expected to have a higher version of the firmware.

For example, in a social networking site, if a beta version of a new feature is released with not many active users using that facility as of today. Any defect found on this feature can be classified as a low priority as the feature takes back seat due to business classification as not important.

Though this feature has a functional defect, as it does not impact the end customers directly, a business stakeholder can classify the defect under low priority, though it has a severe functional impact on the application.

This is a high severity fault but can be prioritized to low priority as it can be fixed with the next release as a change request. Business stakeholders also prioritize this feature as a rarely used feature and do not impact any other features that have a direct impact on user experience. This kind of defect can be classified under the High Severity but Low Priority category.

#4) Low Severity and Low Priority

Any spelling mistakes /font casing/ misalignment in the paragraph of the 3^rd or 4^th page of the application and not in the main or front page/ title.

These defects are classified in the green lines as shown in the figure and occur when there is no functionality impact, but still not meeting the standards to a small degree. Generally, cosmetic errors or say dimensions of a cell in a table on UI are classified here.

For example, if the privacy policy of the website has a spelling mistake, this defect is set as Low Severity and Low Priority.

How to Determine Defect Severity

A defect severity is measured objectively by measuring the consequences from a technical point of view rather than in relation to any deadlines for business reasons or any release schedule. When logging a defect, QA engineers must measure these factors.

Step-by-Step Decision Checklist

Use the following criteria checklist for assigning proper severity (S1 to S4) while logging a new defect into your bug tracking system:

1. System Stability & Execution: Does the defect cause an unhandled crash, blue screen, unhandled exception, or system freeze?

            If Yes → Critical (S1).

2) Functional Blocker: Does the defect completely block a user’s flow or prevents further testing execution in downstream modules? Is there absolutely no workaround from a technical standpoint?

            If Yes to both → Critical (S1).

3) Core Functionality Failure & Workaround Availability: Does the core functionality fail to perform its operations as per the functional specification? Can the operation be achieved through some other way, alternate path, or secondary UI actions?

            If broken without any workaround → Critical (S1).

            If broken but with a workaround → Major (S2).

4) Data Corruption & Security Vulnerability: Does the defect cause data corruption, data exposure without any encryption or even data loss in the database?

            If Yes → Critical (S1) or Major (S2), depending upon the number of impacted records.

5) Scope of Impact: Does the defect impact secondary utilities, non-core modules, or edge case validations?

            If Yes → Minor (S3).

6) Cosmetic Issues & UI Integrity: Are the issues related only to alignment, format, text or styling inconsistencies and have no functional impact at all?

            If Yes → Low or Trivial (S4).

Evaluation Criteria	Critical (S1)	Major (S2)	Minor (S3)	Low / Trivial (S4)
Workaround Status	None available	Available (Complex / Partial)	Available (Simple / Intuitive)	Not required
System Impact	Total crash / Unusable	Functional failure	Secondary feature flaw	Visual / Formatting only
Data Integrity	Severe corruption / Loss	Inaccurate non-critical data	No impact	No impact
Testing Status	Halts test suite execution	Halts specific test module	Test suite continues	Test suite continues

Guidelines

Below are certain guidelines that every tester must try to follow:

• Firstly, understand the concepts of priority and severity well. Avoid confusing one with the other and using them interchangeably. In line with this, follow the severity guidelines published by your organization/team so that everyone agrees.
• Always choose the severity level based on the issue type, as this will affect its priority. Some examples are:
  • For a critical issue, such as the entire system goes down and nothing can be done, this severity should not be used to address program defects.
  • For a major issue, such as where the function is not working as expected, this severity could address new functions or improvements in the current working.
    Remember that choosing the right severity level will give the defect. It’s the due priority.
• As a tester, understand how a particular functionality, rather than drilling down further understand how a particular scenario or test case would affect the end-user. This involves a lot of collaboration and interaction with the development team, Business Analysts, architects, Test lead, and Development lead. In your discussions, you also need to factor in how much time it would take to fix the defect based on its complexity and time to verify this defect.
• Finally, it’s always the product owner who possesses the veto power of the release of the defect that should be fixed. However, since the defect triage sessions contain varied members to present their perspectives on the defect on a case basis, at such a time, if the developers and testers are in sync, it surely helps in influencing the decision.

Frequently Asked Questions about Defect Severity and Priority

Conclusion

While opening defects, it’s a tester’s responsibility to assign the right severity to the defects. Incorrect severity and hence priority mapping can have very drastic implications on the overall STLC process and the product as a whole. In several job interviews, several questions are asked about priority and severity to ensure that as a tester you have these concepts impeccably clear in your mind.

Also, we had seen live examples of how to classify the defect under various Severity/Priority buckets. By now, I wish you had enough clarification on defect classification both in severity/priority buckets.

Hope this article is a complete guide to understanding the defect priority and severity levels. Let us know your thoughts/questions in the comments below.