7.6.1. Concept

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

Severity and priority are essential concepts in bug tracking, helping teams assess and respond to defects effectively. Severity refers to the technical impact a defect has on the system—higher severity means the issue disrupts critical functionality. Priority, on the other hand, indicates how soon a defect needs to be fixed based on business needs and urgency. While severity is assessed by QA/testers, priority is typically determined by product owners and managers who balance the business impact.

Consider a car with a broken brake system. This defect is of 'critical' severity because it jeopardizes safety. However, if the car is scheduled to be serviced next week, the repair might be given a lower priority. On the other hand, a minor scratch on the paint might have low severity but could be prioritized for immediate repair if the car is going to a high-profile event soon.

🎯 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

Each severity level helps categorize defects for clearer communication and priority setting. Critical defects require immediate attention due to their severe impact on functionality. Major defects are significant but do not halt operation. Minor defects might be more about aesthetics and do not affect usability significantly, while trivial defects are minor errors that do not impact the system's performance and can often be addressed later.

Think of a restaurant kitchen: a failed gas line (critical) needs immediate fixing, a malfunctioning oven (major) can continue service with adjustments, a misaligned table setting (minor) may be fixed easily, and a small smudge on a plate (trivial) can be cleaned when noticed but does not interrupt service.

🎯 Priority Examples:

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

Priority levels indicate the urgency of addressing defects. High priority items should be addressed immediately to ensure a timely release. Medium priority items are scheduled for a later development cycle, while low priority items can be addressed at leisure, often related to cosmetic issues that do not impede functionality.

Imagine a software launch: a major security flaw (high priority) needs fixing before anyone can use the software. A minor user interface tweak (medium priority) will be scheduled for the next update. A spelling error in the user manual (low priority) can wait until more significant issues are resolved.

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

There are instances where the severity and priority of a defect do not align. A high-severity defect might be deemed a low priority if there is a workaround available or if it is discovered late in the cycle. Conversely, a low-severity defect might become a high priority if the business determines that it could impact customer perception negatively or reflect poorly on their brand.

In a retail scenario, a major payment processing bug (high severity) might be deprioritized if it happens at a time when transactions are low. Conversely, a minor printing error on a promotional flyer (low severity) may need high priority attention if it's about to go out to thousands of customers.

--