What is meant by severity of a bug? What are different types of severity?

We all know what a software bug is! It is a flaw, error or mistake in the software system or application that can cause it to crash or fail. Pretty much simple!
But very few of us are actually aware about the severity of a bug i.e., how much destruction it can cause to a software system or application.

- Bugs are of course results of the mistakes made by the software programmers and developers while coding the software program.
- Sometimes incorrect compilation of the source code by the program can also cause bugs.
- A buggy program is very hard to clean.
- Bugs can have a chain reaction also i.e., one bug giving rise to another and that in turn giving rise to one more bug and so on.
- Each bug has its own level of severity that it causes to the software system or application.
- While some bugs can work out total destruction of the program, there are some bugs that do not even come in to detection.
- Some bugs can cause the program to go out of service.
- In contrast to these harmful bugs, there are other bugs which are useful such as security bugs.

WHAT IS SEVERITY OF A BUG & ITS TYPES

-"Severity can be thought of as a measure of the harm that can be caused by a bug."
- Severity is an indication of how bad or harmful a bug is.
- The higher the severity of a bug, the more priority it seeks.
- Severity of the bugs of software can sometimes be used as a measure of its overall quality.
- Severity plays a major role in deciding the priority of fixing the bug.
- It is important that the severity of the bugs is assigned in a way that is logical and easy to understand.

There are several criteria depending on which the severity of a bug is measured. Below mentioned is one of the most commonly used ranking scheme for measuring severity of bugs:

1.Severity 1 Bugs
bugs coming under this category cease the meaningful operations that are being operated by a software program or application.

2.Severity 2 Bugs
Bugs coming under this category cause the failure of the software features and functionalities. But, still the application continues to run.

3.Severity 3 Bugs
Bugs coming under this category can cause the software system or application to generate unexpected results and behave abnormally. These bugs are responsible for inconsistency of the software system.

4.Severity 4 Bugs
Bugs coming under these categories basically affect the design of a software system pr application.

COMPONENTS OF SEVERITY
Severity has two main components namely the following:

1. Impact
- It is a measure of the disruption that is caused to the users when they encounter a bug while working.
- There is a certain level to which there is an interference with the user performing a task.
- Even the impact is classified in to various levels.

2. Visibility
- It is the measure of the probability of encountering the bug in future or we can say that it is measure of the closeness of a bug to the execution path.
- It is the frequency of the occurrence of a bug.

The severity is calculated as the product of both the impact as well as visibility. A measure of perceived quality and usefulness of the software product is given by the severity. Therefore it would not be wrong to say that the severity provides an overall measure of the quality of the software system or application.

Team Software Process (TSP) - TSP Quality Management

Team Software Process (TSP) shows teams how to manage quality, teams must establish quality measures, set quality goals, establish plans to meet these goals, measure progress against the plans, and take remedial action when the goals are not met.

ELEMENTS OF TSP QUALITY MANAGEMENT

- Preparing a quality plan.
- Identifying quality problems.
- Finding and preventing quality problems.

PREPARING A QUALITY PLAN
TSP make a quality plan based on the estimated size of the product and historical data on defect injection rates, they estimate how many defects they will inject in each phase. Once the engineers have estimated the defects to be injected, they estimate defect removal,again using historical data or the TSP quality guidelines which are based on the yield for each defect removal phase. Once the injection and
removal estimates have been made, the team can generate the quality plan.

IDENTIFYING QUALITY PROBLEMS
TSP provides many quality measures one of them being is by comparing the data for any module or component with the quality plan. TSP introduces a series of quality measures like: Process quality index—PQI.
- Percent defect free—PDF: Comparing the PDF curves for several similar projects. Where there are problems, the quality manager can look at data on lower level components to identify the source of the problem and recommend what the team should do about it. PDF plot can only be produced for an overall system or large component.
- Defect-removal profile: The defect-removal profile can be drawn for the system, each of its subsystems, any component, or even down to the module level.
- Quality Profile: The quality profile measures the process data for a module against the organization’s quality standards. The five quality profile dimensions indicate module quality based on data for design, design reviews, code reviews, compile defects, and unit test defects.
- Process quality index—PQI: is produced by taking the product of the five dimensional values of the quality profile to produce a single quality figure of merit. With PQI values above about 0.4, program modules are generally defect free.

FINDING AND PREVENTING QUALITY PROBLEMS
The TSP quality measures can indicate likely quality problems even before the first compile. Once the problems are identified, they can be prevented by:
- Monitor the module during test to see if problems are found and then determine the remedial action.
- Reinspect the module before integration or system test.
- Rework on the module to fix suspected problems.
- Redevelop the module.