Wednesday, January 27, 2016

How to Determine your bug’s severity..?

Defect 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)?

Long term:
  • How this bug affects the Stockholders?
  • How this bug affects the Business?
  • Clients, Clients and clients!
Defect 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.

When a tester wants to set the bug “Severity”, he can use few generic levels (the terminology can be different depends on the bug tracking system / organization), the basic classification of bug severity: 


Blocker/Show-Stopper
  • The defect 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 defect causing a massive and repeatedly system failures.
  • There is a massive loss of unrecoverable data. 


Critical
  • The defect 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 defect 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
  • 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 in a reasonable time.
  • The loss of data is minor/Not existing.
  • A defect that affects a major functionality.

Normal/Moderate
  • The defect doesn’t cause a total system failure.
  • There is a quick and satisfied workaround.
  • The defect doesn’t cause a loss of data.
  • The component/function is available for testing, but produce results that has 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.
  • Exist criteria can be fulfill (Depends on the level of risk and the management decisions).

Minor/Trivial
  • Usually involve a cosmetic issue that relevant to the application user interface.
  • The bug occurred on a specific and minor functionality that doesn’t have any effect on the regular system behavior/Flow.
  • No workaround is needed.
  • In 99% will not affect the exit criteria.

Enhancements/Cosmetics
  • Any bugs that contains suggestions to improve the current functionality, Usability or UI.
  • When opening such bugs we can suggest to add/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. 

No comments:

Post a Comment

My Presentations