What is the difference between priority and severity?

Severity and priority have always been the most effective measure to characterize a bug. Severity and priority levels have been in use since a long time by most of the software development organizations and standards as a measure to calculate the degree of the harm that can be done by a bug.

"The severity of a bug is an indication of its harmfulness or badness whereas the priority level of a bug is an indication of the urgency for fixing it."

Role of Testing Team

- The testing team is responsible for setting up the severity as well the priority levels for the bugs.
- The way they set the severity and priority level, it should be meaningful, easy to understand, consistent and of course reasonable!
- A bug as we all know is a defect in the coding of a software program which hinders its development and meeting the expectations of the users.

About Priority

- Priority is way of rating the urgency for fixing or correcting a bug which in turn implies its importance also.
- The priorities are set keeping in mind the goals and the specifications of the software project.
- Priority has nothing to do with the quality of the software product as affected by the bug.
- Priority is nothing but a functional of the class and severity of the bug.

About Severity

- Severity is a means for the measurement of the harm and disruption caused by the bug to the functioning of the software system or application.
- It is the severity that gives the information regarding the impact as well as visibility of the bug on the quality of the software product and its functioning.
- Severity is an effective means for rating of the impact of a bug on the quality of a software product as it is perceived.
- Therefore, the severity of the bugs should be assigned very carefully.
- It is a commonly observed issue that the simple concept of severity is made over complicated due to a lack of data.

Sub-Components of Severity

To say severity has got many sub components but on a whole basis only two are considered:

1. Visibility
Visibility gives the probability of the occurrence of the bug again in the future in a particular feature and functionality of the program.

2. Impact
Impact gives the measure of the disruption caused to the user of the system when the bug is encountered.

How Severity and Priority Calculated?

- The total severity is calculated as an average of the values of the visibility and impact factors.
- This characteristic of severity allows us to view it as a measure of the quality of the software product s it is perceived.
- Using priority as a quality indicator is a great mistake.
- Unlike severity, the priority is measured as an attribute of the bug and the defined goals of the project.

Priority on the basis of Urgency

- Some testers define priority on the basis of the urgency which is an absolutely wrong way.
- The urgency should be defined on the basis of the priority level.
- Urgency is directly proportional to the priority.
- The priority levels range from 1 to 7 where 1 being the highest priority level and 7 being the lowest.
- By default the priority of each discovered bug is 3.
- It will be more good if one priority scheme is followed across all the projects i.e., to have a global priority scheme.
- Priority tells us how important or urgent is to get the bug fixed.

In some cases it happens that going gets tough without rectifying the bugs in the lower levels. Such situations demand the highest priority.

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.