The above question is one that I seem to ask on many occasions. I am yet to find the answer, which I guess would make it much less difficult? I think not since I don’t believe there is an answer to the question, not for me anyway.
The reason I say this relates to the number of people that have ‘buy in’ on how these are defined/classified for various organisations. I’ve heard and researched many schools of thought, and here are but a few:
- Severity is the Business/Customer impact, while Priority is the Test Team impact;
- Severity is the Business/Customer impact, while Priority is simply a guide for the Development Team on which defects to apply effort to first;
- Priority is the Business/Customer impact, while Severity is the same (strange I know, but it’s out there);
- Priority is both (i.e. just use Priority);
- Severity is both (.e. just use Severity); &
- So on and so forth…
Add to all of these the various levels of 1 to 3, 1 to 5, etc, etc. and you have a daylong brainstorming session in itself. The Testing Team like it this way, the Business Team like it that way, then the Development Team like it the way the Testing Team like it with the following tweaks…
Familiar to anyone?
I have sat through many of these sessions trying to come up with the best definitions/classifications to suit the context of the environment/project. I think of the time (and money) that has been spent and wonder if we’ve had return on investment? Have our Testers really looked at the descriptions we came up with when assigning a Priority/Severity? Have the rest of the Project Team? In some cases I’m sure the answer is yes (I know I have anyway), but I fear not enough to warrant the time (and money) spent on the initial development of the definitions.
One method we once used, which I actually quite like, was tied in very closely to the risk based approach we had for the overall Testing Strategy. After identifying the product risks, you assign a weighting/priority right? The old consequence vs. likelihood… Well, when we raised a defect, we would simply use the matrix to come up with the priority of that defect (so there was only one, not both) and it worked quite well.
The organisation used a ‘standard’ and ‘agreed’ risk assessment matrix, so if there were any questions raised in triage we could point to that matrix and the majority (90% +) of people involved knew it already, which saved a lot of time. Maybe not a perfect solution, but definitely a simple one that many people understood quite quickly.
Two things I’ve learned through all of this… Google is your friend (if you only look at the first search result). Google is your foe (if you look at more than one search result). Disclaimer – This is in no way a plug (or the opposite) for Google.
If any readers out there have opinions, thoughts, disagreements, etc. please contact me. The day I retire may be the day I find the answer to my question.
Author Profile – David Greenlees
David has been in the software testing industry for 9 years. He has spent the majority of his career in a tightly regulated government organisation and more recently moved into a consulting role for a specialist software testing organisation. This has given him the freedom to start practicing what he has spent the last few years reading! He is committed to contributing to ‘the community’ that has become so prevalent through the internet and social media. He is looking forward to the future of the industry and the progress that he believes can be made through the learning that can now be shared from one side of the planet to the other!
I liked the solution offered by the BBST Bug Advocacy course. My interpretation:
Severity – A combination of risk and impact, usually assigned by the tester reporting the bug.
Priority – How soon the bug should be fixed in relation to other bugs in the queue; usually assigned by the project manager, since it is a business decision based on many factors beyond the tester’s scope.
It would be great to see an example of this risk assessment matrix. I would guess that there could be significant debate about the matrix. I have also fought this battle without any clear resolution. Severity lost the battle to priority in my case.
I subscribe to severity is impact on all stakeholders and Priority is assessing impact on all resources including stakeholders relative to the value of the issue. Bottom line is as testers we must advocate for resolution to the things that have the most impact.
My understanding is the same as Jeremy’s:
Severity: Describes “how bad” is the defect, is generally assigned by the test team, and generally doesn’t change over time. (e.g., critical, major, average, low). This is usually what is used for Service Level Agreements and needs to be very clearly defined.
Priority: Describes when it should be fixed (e.g., next build = critical, next release = high, can defer but schedule future release = average). This is basically a business decision and again may be driven by SLA criteria.
However … I have yet to see it implemented that way. My favorite was a field that was treated as severity, had states that described priority (e.g. “Urgent”), but was labeled “Risk”.
)