A post about assigning priorities to bugs.
My current client uses an internal defect logging system rather than a proprietary tool. It doesn’t have separate “severity” and “priority” fields, instead we have two fields called “Priority” and “Internal Priority”. In practice testers no longer use the former at all, since all priorities bar the default are now reserved for issues raised by customers via the help desk. So testers use the latter as “our” priority to identify those bugs that need fixing urgently. It’s a numeric field which allows priorities from 1 to 999, although we don’t use anything like the full range.
Without getting into jargon-laden moon-language or buzzword-parody words like “Seriosity”, I’ve used the following two factors in assigning values to this when logging defects found during testing.
First take the importance of the feature in question, on a scale of one to three.
1 – Critical feature on the end-to-end life-cycle of the object under test
2 – Important but non-critical feature
3 – Minor or little-used feature
Note that I’m using “Feature” rather than “Function” here, and the definition of a feature is a level of granularity below the module it’s logged against. For example, a search module blowing up when you press “Go” would be a 1, but an advanced search criteria on the third tab not returning the correct rows might be a 2 or a 3.
Second, take the impact of the bug on the feature in question:
1 – Feature unusable with no workaround
2 – Workaround exists but significant inconvenience to the user
3 – More irritation than inconvenience
Then multiply the two figures together, and you get a figure from 1 to 9 (The numerically-literate among you will notice that you’ll never get 5,7 or 8), and assign that as the Internal Priority. So a critical feature that just doesn’t work at all will be Internal Priority 1, an inconvenience with a workaround on an important function will be 4, and so on.
It’s a bit quick-and-dirty. I know. But it works well enough, and is a little less subjective than “Think of a number between one and six”, and the product owner always has the option of raising or lowering it later.
What rules of thumb to you use for assigning priorities, severities, seriosities or whatever? Are testers even responsible for assigning priorities at the time of logging, or is the deferred to the product owner or a bug triage meeting?
If you run a blog, one of the maintenance chores is dealing with comment spam. They’re usually easy to recongise; either banal “This is a really informative post” or surreal bot-generated gibberish. This was a typical one from a few months back: