Assessing Bug Priority and Severity
The majority of bug databases, whether developed in-house or through third-party tools have some fields that can be filled in-title, priority, severity, opened by, assigned to, and so on. I vigorously advise you to fill in these fields only after the body of the bug report has been created. After writing all of the explanation you pay more attention to the issue, more exactly what the bug is, and in what way is it appears. You can carefully write a short title and set a severity and priority for it.
Most testing teams set these values, but they can differ extremely. Bug priority quantifies how it affects the organization internally and, relative to other software bugs when it should be fixed.
See the example:
- Fix this first. These are all very weighty, very perceptible, or very easy.
- Fix this after all Priority 1 bugs are done. These are weighty, but not at the same level as bugs of Priority 1.
- Fix these after the Priority 2s. These have an influence on the quality of the product, but not so high that they would stop the shipment.
- Fix these last. Usually, these are very marginal cases that customers would not face in the common use of the application.
The severity of the bugs portrays the influence that it would have on a customer’s risk and visibility. The strictest impact is a failure of the product or destruction of data or wrong unsuitable result.
See the example:
- The software bug causes perceptible trouble, but the user can work around it.
- The software bug affects client or server machines to failure, hesitation, ruin, or corrupt data.
- The bug describes a trivial issue that is not expected to be a problem. It might be a suggestion or a predilection of the software tester.
- The bug makes a feature useless or presents serious trouble to the user.
Learn more from QATestLab
Related Posts:
About Article Author
view more articles
No Comments Yet!
You can be the one to start a conversation.