When raising a defect, there is a common confusion that occurs for testers and others alike. What is the difference between a defects severity and its priority?So let’s start with looking at the dictionary definitions:
Severity - Causing very great pain, difficulty, anxiety, damage, etc.
Priority - Something that is very important and must be dealt with before other things.
We can see that the two words have completely different meanings. Why then is their confusion between them?
The severity is the domain of the tester and they should be capable of recording this. The severity to the testers is the impact of the defect on the application and their ability to continue testing. The priority is the domain of the business and should be entered by them against each defect raised to reflect the importance of the change to them.
For instance, a spelling mistake would be deemed as a low severity by the tester, but if this mistake occurs in the company name or address, this would be classed as high priority by the business. An inability to access a rarely used menu option may be of low priority to the business, but the severity is high as a series of tests cannot be executed, all dependent on access to the option.
The mistake that we have seen made many times is to assume that the tester is also capable of recording the priority. Whilst it may be possible for the tester to make an educated assessment, the priority is the business’ means of defining what must be repaired prior to release to production and the order in which effort should be applied to the fixing of defects. Testers who have been involved with a particular application for some period of time may be able to do this, but it is essential to have adequate business representation on the project and their involvement in the life-cycle of a defect and the defect management process.
When a project enters test execution, the focus will be on fixing defects of the highest priority. This means that the application will be released with the minimum amount of priority defects unresolved. Care should be taken by the Project Manager to ensure that whilst the priority is paramount, severity is not ignored. What is needed is a balanced approach, which favours the business priority. At the end of the project the volume of high severity and high priority defects should have at least been reduced, if not removed, in order to meet the exit criteria defined in the test strategy.
To summarize:
Priority = Business = Order of Fixing
Severity = Tester = Failure of Application
A very interesting little blog! Definitions abound in the literature. [ Maybe to little purpose! Brian Beaver, in Sticky Minds, says "... (the) fields, Priority and Severity, seem of questionable usefulness! ]
ReplyDeleteI've always worked on the basis that:
"Severity" reflects the impact to the business were the defect to arise in production.
"Priority" reflects testing's need to get the defect fixed so that testing is not unduly held up.
In practice, I've seen little real need for both - if "severity" is set to "High", you can usually rely on "priority" being set "High" too!
Beaver suggests replacing both of them with one field - the "Customer Impact Field". I'm not so sure, but he may have struck a chord!
It is interesting that your own interpretation seems to contradict the article. Who is right I wonder?
ReplyDeleteI think that you are right about severity and priority often being set to similar values and have often seen this myself. I would however suggest that if you assume the meanings given are correct, that instances will arise where having both will help. Perhaps this is more to resolve internal project conflicts, or when backs are against the wall and knowing which defects must be fixed prior to go-live requires improved differentiation.