how to give bugs the correct (and objective) severity?
I know of at least 2 ways to set the priority of each bug correctly, the hard way and the easy way.The hard way: to define the Severity each time from scratch
Sadly enough most groups work this way, asking their testers and/or bug-reporters to set the severity based on a scale (of either 3 or 5 levels) according to their objective understanding of the harm the bug causes the system or end-user.
What’s the problem with this approach?
1. It’s not objective, so two people may look at the same bug and set 2 different severities.
2. It usually gathers bugs towards the middle of the scale.
From personal experience if you leave your severity definition to the testers’ gut-feeling, the bug distribution at the end of the project will look like a normal curve.
At first you may think this is OK but think again… There is no logical explanation for this behavior, on the contrary for many or most projects you expect to see shifts to the right or left based on factors such as the maturity of the team, application, technology, etc.
My explanation is that we like to do things on a balanced way, so unconsciously we try to balance even the severities of the bugs we report (don’t blame your mother, its genetic…).
3. Your severity appreciation can shift with time.
You may have seen this in the past projects, as we advance in our testing we may look at a bug we reported in the past and feel that we gave it a severity that is too high compared to the ones we are reporting today.
This may be related to the old saying: “just when you though things can’t get any worst, they usually do”.
The easy way: create a Severity Look-up Table
In my opinion the best way to give the correct severity is by having a look-up table to help us classify our bugs. By thinking ahead of time about most bug cases and creating a table we are able to classify bugs more accurately and based on a standard system.
An example of a Severity Look-up Table I’ve used in the past is the following:
S1 – Critical
A defect that causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround.
Additional specific bugs:
- Spelling or Grammar Mistakes
- Important bugs that were reported from customers and we assured them will be fixed.
S2 – High
The defect causes a part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users.
Additional specific bugs:
- High visibility GUI issues.
S3 – Medium
The defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users.
S4 – Low
The defect causes no dysfunctions to the system and may even be unnoticed by most users . The bug has an easy workaround or may not even require a workaround at all.
S5 – Enhancement Request or Suggestion
No need to explain.
Notice that on some levels I added specific cases that even if they don’t fit the definition of the severity will still make it to that level. This is a practice that will help you include your specific issue themes into the Severity Look-up table.
Each Organization / Team / Project may need to review or fine-tune their Severity Look-up Table once in a while based on their individual definitions, requirements and customer needs.
I remember once I told a group I was training about this practice. A young tester got up and said that she thought using a Look-up Table would make her look inexperienced and unprofessional.
My reply was that I still use lists like this in almost every project I work, and that it would be less professional to use another approach if she knew that this one was easier and gave better results…
http://qablog.practitest.com/2008/12/using-a-severity-look-up-table-for-better-and-more-accurate-bug-classification/
No hay comentarios.:
Publicar un comentario