How to Determine your bug’s severity..?
Updated: Mar 3, 2022
Bug severity determines the impact that the bug has on the system, both in the short and long term. I want to explain:
How this bug affects the development phase?
How this bug affects the testing phase?
How this bug affects the global project timelines?
How this bug affects the level of risk (If we decide to fix/not fix it).
How this bug affects the Stockholders?
How this bug affects the Business?
Clients, Clients, and clients!
Bug severity is determined by the tester (when he opens the bug), who needs to determine the severity level based on the Short and long-term concepts. In most cases, we will classify the bug severity based on the level of impact that the bug has on the tested software; the effect can be on specific functionality, component, or the entire system.
The Bug has a massive impact on the tested software (System/Component/feature); this Impact will cause the stop of testing until the bug is fixed.
No workaround may help to overcome the problem.
Exit criteria will not be fulfilled until Blocker bugs are fixed and verified.
The Bug causes massive and repeated system failures.
There is a massive loss of unrecoverable data.
The Bug has a massive impact on the tested software (System/Component/feature). A workaround is available (Although it’s tough to create one...) under a reasonable time.
Although the Bug has a significant impact on the tests, the tester can continue his tests on related/stand-alone features/components Etc.
Exit criteria will not be fulfilled until Critical bugs are fixed and verified.
Major bugs can affect the exit criteria so that the software cannot be released.
The workaround has allowed the test to be continued.
A workaround is available at a reasonable time.
The loss of data is minor/Not existing.
A Bug that affects a significant functionality.
The Bug doesn’t cause a total system failure.
There is a quick and satisfying workaround.
The Bug doesn’t cause a loss of data.
The component/function is available for testing but produces results that are deviations from the original requirements (usually false positives…).
This bug doesn’t affect the system level or cross components; the tester can continue his tests.
Exit criteria can be fulfilled (Depending on the level of risk and the management decisions).
Usually, it involves a cosmetic issue relevant to the application user interface.
The bug occurred on specific and minor functionality that doesn’t affect the regular system behavior/Flow.
No workaround is needed.
99% will not affect the exit criteria.
Any bugs that contain suggestions to improve the current functionality, Usability, or UI.
When opening such bugs, we can suggest adding/adjusting/removing functionality that contributes to the software.
Bugs of this kind are not affecting the system at any level.
Bugs are not affecting the Exit criteria.