A good practice for companies to schedule the ordering of the tickets workflow is by adding priority and severity levels.
Priority and Severity differences
Even though they can be frequently intertwined, there is a difference between the priority and severity levels.
1. One of the stakeholders, project managers, the product owner, or the client usually sets the priority of the bug. This is used for prioritizing the workflow based on the business needs.
2. The QA is usually responsible for adding the severity level when creating the bug. A severity level is added based on the criticality and complexity of that bug.
ISTQB Definition: https://www.istqb.org
–severity: The degree of impact that a defect has on the development or operation of a component or system.
The defect severity can have different classifications based on the project, organization, tracking tool, or others. We will exemplify a generally used classification.
Severity is how austere a bug is. The severity of a bug is derived based on the effect of that bug on the system. It indicates the level of threat that a bug can affect the system. Severity is divided into levels, such as:
The defect is affecting the basic functionality of the application and there is no workaround it, there is data loss or serious damage. For example, a complete failure of a feature.
It is affecting a major functionality of the application but there is a less intuitive workaround in order to still use the application. For example, the only way to move forward from a page is by doing a few unintuitive actions.
A minor defect does not affect the functionality, or it affects it in a non-critical way and there is an easy workaround. For example, a minor feature that cannot be accessed from all modules of the app.
This type of defect is not affecting the functionality or the testing process. It happens when, for instance, the text does not fit in a separate bar, incorrect hyphenation, missing space in a particular place, etc.
Since the QA is responsible for setting the Severity level of the bugs added, we have focused more on this part, but the priority of the defect is also an important aspect.
The priority levels are classified similar to the severy levels as per below:
- Highest – this obstruction needs to be fixed and deployed as soon as possible
- High – the defect needs to be deployed with the next release
- Medium – it may be considered in the upcoming release or the next one
- Low – will receive less attention, it may or may not be fixed
To keep in mind is that the priority level may not always coincide with the severity level. Even though a defect has critical severity it might not be the highest priority for the client and vice versa.
As an example, a Critical issue with Low priority can be when the application crashes after taking many steps that normal users don’t usually follow (adding more than 50 phone numbers on an account registration page).
A Trivial/Minor bug that can have a High priority is when an image is truncated and not centered on a certain page. This issue will probably have a High priority for the client since this directly affects the user experience.
This is one of the most common causes of conflict between the QA and the Developer, where the QA will set a bug to Major or Critical and the Developer will consider it as Minor/Trivial.
Make sure to always add the correct criticality level in order for the bugs to be better prioritized and to avoid any conflicts with developers. At the same time do not be upset if a Low priority is added to a Critical issue because fixing this issue is probably not important for reaching the company goals at the moment.