7.6.2 - Severity
Enroll to start learning
Youβve not yet enrolled in this course. Please enroll for free to listen to audio lessons, classroom podcasts and take practice test.
Interactive Audio Lesson
Listen to a student-teacher conversation explaining the topic in a relatable way.
Understanding Severity
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Today, weβll dive into the concept of severity in defect management. Can anyone tell me what severity means in this context?
Is it about how big the problem is?
Exactly! Severity assesses the technical impact of a defect. For instance, a critical severity defect might crash the application, while a trivial one could just involve a minor typo.
So, critical and trivial are examples of severity levels?
Yes! Remember the acronym 'CMMT' for Critical, Major, Minor, and Trivial to recall the different severity levels.
Got it! But how do we differentiate it from priority?
Great question! Priority refers to how urgently we need to fix the defect, which can vary regardless of its severity. Let's summarize: severity measures technical impact, while priority measures business urgency.
Severity Examples
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Letβs go through some examples of severity levels. Can anyone give an example of a critical severity defect?
An app crash when logging in!
Correct! That type of defect prevents any usage of the application. What about a major severity issue?
A wrong calculation on an invoice!
Exactly! That impacts user trust and financial dealings. Now, how about a minor severity example?
A misaligned button on the interface?
Very good! And trivial? Any thoughts?
A typo in the footer of the app.
Well done! Keeping these examples and classifications in mind is crucial for effectively managing defects.
The Importance of Severity
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Why do you think understanding severity is important in defect management?
It helps prioritize how we deal with bugs?
Exactly! Understanding severity ensures that we focus our resources on the most impactful defective behaviours. For instance, prioritizing fixes for critical defects can mean the difference between a functioning application and an unusable one.
Got it! So it's about managing our efforts wisely.
That's right! Remember that communication is key; articulating severity and priority helps align the teamβs efforts.
Introduction & Overview
Read summaries of the section's main ideas at different levels of detail.
Quick Overview
Standard
In this section, we explore the severity levels of software defects and how they differ from the priority of addressing those defects. Examples are provided to illustrate different severity categories, emphasizing that a defect's severity indicates its technical impact, while priority indicates the urgency of fixing it.
Detailed
Severity in Defect Management
Severity is a critical factor in defect management, often used alongside priority to determine the best course of action for resolving bugs.
Definition
- Severity refers to the technical impact a defect has on the system, assessed by Quality Assurance (QA) teams or testers. It classifies defects based on how significantly they affect functionality. Severity can range from 'Critical', where the application crashes, to 'Trivial', which may involve minor typographical errors that do not affect usability.
Severity Examples:
- Critical Severity: App crashes on login β immediate attention required.
- Major Severity: Wrong calculations in invoices β high impact on user trust.
- Minor Severity: UI alignment issues β cosmetic but should be fixed when possible.
- Trivial Severity: Typographical mistakes β low priority corrective actions.
Comparison with Priority
- Priority indicates the urgency to fix the defect from a business perspective, often decided by managers or stakeholders. For instance, a defect may have a high severity but low priority if it does not impact business operations significantly, or vice versa.
Understanding severity not only helps teams effectively categorize defects but also assists in better communication and resolution management within a development lifecycle.
Audio Book
Dive deep into the subject with an immersive audiobook experience.
Understanding Severity
Chapter 1 of 4
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
Two key attributes are used to evaluate the impact and urgency of a defect:
| Factor | Severity | Priority |
|---|---|---|
| What it | Technical impact of the bug on the | Business urgency to fix it |
| means | system | |
| Decided | QA/Testers | Product Owners/Managers |
Detailed Explanation
Severity refers to the technical impact that a defect has on a software system. It determines how serious the defect is from a technical standpoint. For example, if a bug causes the entire application to crash, this would be considered a high severity defect. Priority, on the other hand, is about the urgency of fixing the defect. This is decided by product owners or managers based on business needs, like deadlines or release schedules.
Examples & Analogies
Imagine you have a car. If the engine fails, that's a high severity issue because the car cannot run. However, if there's a small scratch on the paint, while it may be low severity, fixing it might be prioritized differently based on how much it impacts the car's appearance or your plan to sell it.
Labels of Severity
Chapter 2 of 4
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
π― 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
Detailed Explanation
The severity of defects is categorized into different labels. A 'Critical' severity defect might cause a complete failure of the application, making it unusable. 'Major' severity issues could have significant impacts but may not bring down the entire application. 'Minor' severity defects are those that might affect usability but do not hinder the application's main functions. 'Trivial' defects are the least critical, often just cosmetic issues.
Examples & Analogies
Think of a restaurant. If the kitchen is on fire, that's a critical issue (critical severity). If the food has the wrong spice level, that's a major issue. If a table is slightly wobbly, that's a minor issue. And if thereβs a small misspelling on the menu, thatβs trivial.
Understanding Priority
Chapter 3 of 4
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
π― Priority Examples:
- High: Fix required before release
- Medium: Can be scheduled in next sprint
- Low: Cosmetic issue, fix in future release
Detailed Explanation
Priority reflects how soon a bug should be fixed based on the impact on the business. A high priority defect needs to be addressed immediately, especially if it's preventing a release. A medium priority defect can be fixed in the next update cycle, while a low priority defect can wait until a future release, often due to its minor impact.
Examples & Analogies
Imagine working on a project with a deadline. If you have an issue that prevents you from submitting your work (like a system crash), itβs a high priority to fix it. If thereβs a minor issue, like a mislabeled file that doesnβt impact functionality, it can be fixed later β thatβs low priority.
Severity and Priority Relationship
Chapter 4 of 4
π Unlock Audio Chapter
Sign up and enroll to access the full audio experience
Chapter Content
π A defect can be High Severity + Low Priority, or Low Severity + High Priority, depending on business needs.
Detailed Explanation
Not all defects with high severity are considered high priority. For instance, a critical bug found just before a release might be urgent to fix, while a low severity issue found in a non-critical part of the system might be prioritized higher because it aligns with business objectives, like upcoming features. This flexibility allows teams to manage resources effectively.
Examples & Analogies
Consider a school preparing for graduation. If a student's final paper has critical errors but it's submitted at the last minute, itβs high severity but might not be prioritized to be fixed right away. Conversely, if a minor error in the graduation program is caught, it might be fixed immediately because it impacts the ceremony β thatβs low severity but high priority.
Key Concepts
-
Severity: A ranking of how much a bug affects the technical functionality of an application.
-
Priority: A ranking of how urgent it is to resolve a bug from a business perspective.
-
Critical Severity: A defect that prevents the use of the application.
-
Major Severity: A defect that affects significant application functionality.
-
Minor Severity: A defect that represents minor usability issues.
-
Trivial Severity: A defect with minimal impact on functionality.
Examples & Applications
A critical severity defect occurs when the application crashes, halting all operations.
A major severity defect can result in incorrect calculations, impacting financial records significantly.
A minor severity defect may involve slight misalignments in user interface elements.
A trivial severity defect might be a simple typo that doesnβt hinder any functionality.
Memory Aids
Interactive tools to help you remember key concepts
Rhymes
When bugs are critical, it stops the fun, / Major and minor, but trivial's a pun.
Stories
Imagine a team racing to fix a car. A flat tire (critical) stops the car completely, while a dent (minor) isnβt urgent at all. They prioritize fixing the tire first, demonstrating how severity works.
Memory Tools
Remember 'CMMT' - Critical, Major, Minor, Trivial for severity classification.
Acronyms
Use 'SPIV' for Severity Priority Interaction Value β it helps you remember the distinction between severity and priority.
Flash Cards
Glossary
- Severity
The technical impact a defect has on the system, indicating its seriousness.
- Priority
The urgency to fix a defect, determining its immediate importance within business operations.
- Critical Severity
A severity classification where the defect causes significant failures, often leading to system crashes.
- Major Severity
A classification where the defect affects significant functionality, potentially causing major disruptions.
- Minor Severity
A defect classification that denotes minor issues which have a minimal effect on functionality.
- Trivial Severity
A classification for defects that are negligible and do not impact application functionality.
Reference links
Supplementary resources to enhance your learning experience.