7.3. Severity vs Priority

Two key attributes are used to evaluate the impact and urgency of a defect:

In software testing, severity and priority are two important factors used to assess defects. Severity refers to the technical impact that a bug has on the software system. This measure indicates how severely the defect disrupts the software's functionality. On the other hand, priority indicates the urgency of resolving the defect from a business perspective. It is determined by how quickly a defect needs to be fixed based on business operations or user needs. QA testers typically assess severity, while product owners or managers assign priority.

Imagine you're running a restaurant. If a critical issue arises in your kitchen where the ovens break down completely, this is high severity because it stops food from being cooked — a major operational failure. However, if the restaurant has a minor issue like one missing menu item, it is low severity. However, if a famous food critic is dining that night and has requested that item, the urgency to address it becomes high priority despite it being low severity.

🎯 Severity Examples:

• Critical: App crashes on login
• Major: Wrong calculation in an invoice total
• Minor: UI alignment issue on help page
• Trivial: Typo in footer text

This section outlines examples of severity levels assigned to defects. A 'Critical' severity indicates issues that cause significant disruption, like an app crash that prevents users from logging in. A 'Major' severity defect may not completely halt operations but can significantly affect important functions, such as miscalculating invoice totals. 'Minor' defects are less severe, such as minor UI alignment issues that do not hinder functionality, while 'Trivial' defects are cosmetic problems—like typos—that do not affect the software's usability.

Think of severity as a medical emergency scale. A critical condition that requires immediate attention (like a heart attack) is analogous to a critical software defect. A major condition (like a broken arm) needs prompt care but isn’t as life-threatening, similar to a major software bug. Minor issues (like a cold) might not require urgent care, akin to minor UI issues. Trivial problems (like a scratch) are like minor cosmetic issues that don’t impact the overall health.

🎯 Priority Examples:

• High: Fix required before release
• Medium: Can be scheduled in next sprint
• Low: Cosmetic issue, fix in future release

In this section, we explore different levels of priority assigned to defects. A 'High' priority means that the defect must be addressed immediately, often before a product release. For example, if a critical feature does not work, this would be high priority. 'Medium' priority indicates that while the defect needs to be fixed, it can wait until the next development phase or sprint. 'Low' priority refers to defects that can be postponed indefinitely, usually those that do not affect user experience significantly, like minor visual issues.

Think of prioritizing tasks at home. If your roof is leaking (high priority), it needs to be fixed right away. If your garden needs weeding (medium priority), you can schedule that for next weekend. Finally, if your fence needs painting (low priority), that can wait until you have extra time — it’s not urgent.

🔄 A defect can be High Severity + Low Priority, or Low Severity + High Priority, depending on business needs.

This statement highlights that severity and priority do not always align. A defect can have high severity, meaning it significantly impacts the system technically, but its priority can be low if the business does not need it fixed immediately. Conversely, a defect with low severity may be marked as high priority if it needs a quick fix due to business needs, like keeping a client happy. This flexibility allows teams to respond effectively based on context and resources.

Consider a smartphone app that crashes when a user logs in — this is high severity. However, if the application is in the late stages of its lifecycle and a new, improved version is about to launch, fixing the crash might be lower in priority. On the flip side, imagine a minor bug that causes an application to not display correctly, but it affects a high-profile client's project — this could be considered high priority despite being low severity.

--