Severity And Priority With Real Time Examples In Testing

Difference Between Severity And Priority With Real Time Examples In Testing: Defining severity and priority levels is crucial in software testing to allocate resources efficiently. Severity indicates the impact of a defect – how severely it affects the system and users. Priority indicates the importance of fixing a particular defect.

Real-time examples help illustrate concepts of high/low severity and priority. A high-severity, low-priority defect could be a distorted company logo on a website welcome page. This is visually unappealing but doesn’t affect site functionality. On the other hand, a low severity but high priority defect may be mismatched text colours, violating style guidelines but not impeding site use.

When a new software bug is found, it gets logged with details like a description, the app version, steps to recreate it, and who reported it. The most important details are severity and priority. Severity means how bad the bug is. Priority tells the order it should be fixed. These help teams fix critical bugs first and decide what goes into each release.

What Is Severity Mean?

Severity indicates the disruption a software defect causes to system functionality and usability. The high-severity defects greatly impact the system’s intended purpose and performance. Defects with low severity have minor effects that do not significantly hinder the system’s operation.

Severity helps QA engineers categorize and prioritize defects based on their influence on intended software behaviour. Defects that completely disable main system functions have the highest severity as they render the software unusable for practical purposes.

Less critical defects like visual inconsistencies have very low severity as they do not prevent users from completing key tasks. Thoughtfully assigning severity enables testers to focus repair efforts on bugs undermining the software’s core value.

Different Severity Levels

• Critical: If a defect causes the termination or complete shutdown of the application, then it is “Critical”.
• Major: If the defect results in the termination of the system but one or more alternative methods exist to achieve the desired results or use the system, then the defect is said to have the level “Major”.
• Minor: A defect is marked as “Minor” when the usability or functionality of the system is not affected much but must be fixed. Small corrections obtain the results, and the defect causes no system breakdown.
• Low: Defects related to the look and feel of the system are given the severity “Low”.

What Is Priority In Testing?

Priority indicates the importance and urgency of fixing a particular software defect. It establishes a hierarchy for how testers and developers should address bugs.

Defects with high priority are critical issues that require immediate attention and resolution. High-priority bugs significantly disrupt critical user workflows and software functionality. Teams should fix these urgent defects first based on input from customers and stakeholders.

Low-priority defects have relatively minor impacts on the user experience and overall performance. While these should still get addressed, they do not need to be resolved as quickly as high-priority bugs.

Testers set the priority level when reporting defects to point out which issues require the development team’s most timely focus, enabling efficient allocation of repair efforts. Overall, priority helps QA and development team members coordinate to resolve the most pressing defects causing software failures.

Different Levels of Priority

• Low: A defect that can be deferred or fixed in the later stages once the higher priority ones are fixed, as it is not serious from the requirement point of view, is of low priority.
• Medium: A defect that needs to be fixed during the normal course of development activity is given the status of “Medium”. Such defects occur when a feature cannot be used the way it should be because of some environmental issue, defect in the program, or some code that must be added. Usually, these defects are fixed and delivered to the testing team as a part of a new release.
• High: Those defects that need to be fixed as soon as possible so that the testing team can continue with the testing are said to be of high priority. The core functionality fails due to such defects, and the system cannot be tested or used until the defect is fixed.

Who decides the Severity and Priority of a Defect?

The organization decides the standards regarding who sets the priority and severity of a defect. However, in most cases, the tester sets the severity type of a defect based on the product functionality and the written test cases. The product manager decides the priority based on customer requirements.

Difference Between Severity And Priority In Testing

Here is a tabular comparison of severity and priority:

Features	Severity	Priority
Definition	Severity denotes the impact of a defect on software functionality.	Priority indicates the order to fix defects.
Purpose	Indicates how severely the defect affects functionality.	Defines urgency to resolve the defect.
Relation	Related to quality standards.	Related to scheduling fixes.
Categories	Critical, Major, Medium, Low	High, Medium, Low
Who Decides	The testing engineer decides the severity.	The product manager decides on priority.
Value	Objective does not normally change	Subjective can change based on context
Value Change	Doesn’t change over time.	Changes over time.
Association	Associated with functionality.	Associated with scheduling.
Indication	Indicates defect seriousness.	Indicates fix urgency.
Driving Factor	Driven by functionality.	Driven by business value.
Based On	Based on technical aspects.	Based on customer needs.
Implications	If high severity and low priority, fix but not immediately	If high priority and low severity, fix immediately

In a separate blog post, we have discussed the difference between Severity Vs Priority In Software Testing in detail; you can check by following the hyperlink.

Common Scenarios Severity And Priority

• Consider a defect that does not permit the tester to continue with the testing at any cost or causes the application to crash. Even the basic/main functionality does not work as expected. Such a defect is considered a high priority and high severity example.
• A defect that is visible to the customer but is not likely to affect the app’s functionality, such as an issue with the logo or a spelling mistake, is considered a high priority and low severity example.
• A defect that causes the system to crash and makes the system unusable but happens only when the user clicks on any link that is not used normally is considered a defect with high severity and low priority example.
• A cosmetic error not visible during normal use is considered a low severity and low priority example.

Severity And Priority With Example

Let us understand the severity and priority examples by considering an e-commerce application like amazon.com.

High Severity And Low Priority Example

Suppose the tester clicks on the “Privacy” hyperlink at the bottom of the amazon.com homepage, and the page is not displayed. This defect will be of high severity because the functionality is not working. The priority is low because people do not normally spend time reading the privacy notice.

For example, having multiple flows of one task but one of that which is rarely used is not working.

High Priority And High Severity Example

You log in to your amazon.com account, add items to the cart, and click the “Proceed to Checkout” button. You make the payment, and the system crashes. This defect makes the whole buying functionality unusable, so the severity is high.

The basic purpose of amazon.com is to buy and sell products; most customers are affected by this. So, this defect is highly prioritized and must be fixed immediately for the buying process to work.

High Priority And Low Severity Example

Suppose that on the amazon.com website, the logo is displayed as ”amazn.com” with the letter “o” missing. This defect does not affect the buying/selling or any other functionality.

So, the severity of this defect is low. However, a mistake in the company logo affects the brand identity and user experience. So, the defect is of high priority.

Another Example:

Suppose the Flipkart logo is misspelled as Flipkart. That time directly impacted Flipkart’s online business. People will think it’s not a genuine product and won’t buy it. Business impact is huge. So it got a very high priority issue. However, for developers, fixing this issue is not that difficult. It does not even break any workflow. So, the severity is very low.

Example 2: Company logo put opposite. so this is not a functionality impact but a high business impact.

Example 3: An example of low severity and high priority is that the About Us page gives an error message. It is not blocking any business flow, so it is low severity; every business must display an about us page, which is a high priority.

Low Severity And Low Priority Example

Suppose the tester clicks on the “Conditions of Use” hyperlink at the bottom of the amazon.com homepage. Suppose there is an alignment issue in the text displayed or a spelling mistake in the content displayed.

In that case, the defect is said to be of low priority because people rarely read this page, and it does not impact the user experience. The severity is also low because the application’s functionality is not affected.

Summary

Defining severity and priority levels is integral to efficient defect management in the software development life cycle. As summarized in this article, severity denotes the technical impact of a defect, while priority indicates the business urgency to resolve an issue based on customer needs.

Thoughtfully setting these metrics allows testers and developers to coordinate repair efforts effectively. By categorizing defects along the spectra of high to low severity and priority, teams can strategically allocate resources to fix issues.

We encourage readers to apply these learnings about severity and priority to optimize testing and debugging processes within their organizations. Additionally, please provide any feedback or suggestions to enhance the frameworks presented here or share real-world examples illustrating these concepts.

Collaborating across teams and companies will help refine best practices for defect categorization. Testers with robust severity-priority guidelines can target test planning for maximum software quality and customer satisfaction. Please leave your insights in the comments!

FAQs

What is severity and priority?

Severity denotes the impact of a defect. Priority indicates the urgency to fix a defect.

What is the difference between severity and priority in software testing?

Severity focuses on technical functionality. Priority focuses on business objectives. Testers assign severity, and product managers assign priority.

How do you set defect priority and severity?

Analyze the impact on functionality to set severity. Analyze business needs and user impact to set priority. Use defined criteria to assign high/low values.

Who decides severity and priority in testing?

Testers decide severity levels. Product managers, with customer input, decide on priority status.

What is the difference between severity and priority?

Severity indicates the technical impact. Priority measures the business importance of fixing issues.

Why is it important to assign both severity and priority levels to a defect?

It allows coordinated focus on high-impact & urgent bugs. Enables strategic test resource allocation.

How do we determine priority and severity?

Methodically analyze defect impact and implications. Consistently apply predefined categorization criteria.