Severity
Severity is a classification used to measure the degree of impact that a defect, risk, or incident has on a system, project, or business operation. It helps teams understand the seriousness of an issue, distinct from its priority, which dictates the urgency of fixing it.
First used·Early 20th Century
Definitions·3
Synonyms·4
Category·Software Development
Also known as
Definitions
What it means.
- 01
Severity in Software Testing & Quality Assurance
In software testing and quality assurance, severity refers to the degree of impact a defect or bug has on the development or operation of an application. It is a measure of the bug's effect on the system's functionality and is typically determined by the Quality Assurance (QA) team.
Severity levels help teams understand the technical impact of a problem. Common levels include:
- Blocker/Critical: The defect completely prevents the use of a core feature or the entire application. There is no workaround.
- Major: The defect causes a significant loss of functionality or data corruption, but a workaround exists.
- Minor: The defect affects a non-critical function or is a cosmetic issue that impacts the user experience but doesn't prevent the user from completing a task.
- Trivial/Low: A very minor issue, such as a typo in a non-critical text label or a slight UI misalignment, that has a minimal impact on the user.
- 02
Severity in Project & Risk Management
In the context of project and risk management, severity (often called impact or consequence) is a component of risk analysis. It measures the potential negative effect a risk would have on project objectives, such as schedule, budget, scope, or quality, if it were to occur.
Severity is often combined with the probability (or likelihood) of the risk occurring to calculate an overall risk score. This score helps project managers prioritize which risks require mitigation plans. For example, a risk with high severity and high probability is a top priority, while a risk with high severity but low probability might be monitored.
- 03
Severity in Incident Management (ITSM)
In IT Service Management (ITSM) and incident management, severity quantifies the impact an incident (like a service outage or performance degradation) has on business operations and service levels. It is a critical factor in determining the response and resolution priority.
Assigning a severity level helps organizations trigger the correct response procedures, allocate appropriate resources, and adhere to Service Level Agreements (SLAs). For instance, a 'Severity 1' incident typically signifies a critical business outage affecting all users and requires an immediate, all-hands-on-deck response.
Origin
Where it comes from.
Etymology
The term 'severity' originates from the Late Latin word 'severitatem' (nominative 'severitas'), meaning 'seriousness, sternness, strictness,' which comes from the Latin 'severus,' meaning 'serious, grave, strict.' Its use in technical fields adopts the sense of 'gravity' or 'seriousness' of an issue's impact.
Historical context
The concept of assessing the 'severity' of a problem has its roots in traditional engineering and risk management disciplines in the early 20th century, where evaluating the potential consequences of a failure was crucial for safety and reliability.
With the rise of software engineering in the latter half of the 20th century, the term was formally adopted to classify software defects. Early bug tracking systems in the 1970s and 1980s began to incorporate fields for both severity and priority to help manage the complex process of debugging.
The formalization of frameworks like ITIL (Information Technology Infrastructure Library) further cemented the role of severity in incident and problem management, defining it as a key metric for determining operational impact and guiding response protocols.
Usage
In context.
The QA team classified the data corruption bug with the highest severity because it made the entire application unusable.
In our risk assessment meeting, we need to determine the severity of a potential server failure; its consequence on business operations could be catastrophic.
Although the typo is a low-severity issue, the product manager has raised its priority because it's on the homepage.
The criticality of the security vulnerability was rated as 'High', so we must address it immediately, regardless of the development sprint schedule.
FAQ
Common questions.
Severity measures the impact of an issue on the system or business. It answers the question, 'How bad is the problem?'
Priority, on the other hand, determines the order in which an issue should be addressed. It answers the question, 'How soon should this be fixed?'
A high-severity bug (e.g., a data corruption issue) might be given a lower priority if it only occurs in a rare edge case and has a simple workaround.
Taxonomy
Filed under.
Categories
Tags