Updated: Dec 2, 2020
Bug severity determines the level of impact that the bug has on the system, both in the short and long term. I want to explain: Short term:
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 need to determine the severity level based on the Short and long-term concept. In most cases we will classify the bug severity based on the level of impact that the bug has on the tested software, the impact 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 will be fixed.
There is no workaround that may help to overcome the problem.
Exit criteria will not fulfill until Blocker bugs are fixed and verified.
The Bug causing massive and repeatedly 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 very hard to create one...) under a reasonable time.
Although the Bug has a huge impact on the tests, the tester can continue his tests on related/stand-alone features/components Etc.
Exit criteria will not fulfill until Critical bugs are fixed and verified.
Major bugs can affect the exit criteria in a way 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 major 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 produce results that have a deviation from the original requirements (usually false positives…).
This bug doesn’t have an effect on the system level or on cross components, the tester can continuing is tests.
Exit criteria can be fulfilled (Depends on the level of risk and the management decisions).
Usually, involve a cosmetic issue that relevant to the application user interface.
The bug occurred on specific and minor functionality that doesn’t have any effect on 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/Adjust/remove functionality that should contribute to the software.
Bugs from this kind are not affecting the system at any level.
Bugs are not affecting the Exit criteria.