IMO, Priority should not be populated by testers. My teams use a customized version of Microsoft Team Foundation Server’s bug work item template. For whatever reason, Priority is a required attribute upon logging bugs. It defaults to “Medium” and I never change it.
From my experiences, testers often overstate bug priority, wanting to believe the bugs they found are more important to fix than other work that could be done. Some testers see themselves as the saviors of the user-in-distress. I see myself as the information gatherer for my development team and stakeholders. I don’t understand the business needs as well as my stakeholders, thus I remove myself from making claims about bug priority.
- Priority is a stakeholder question and it’s always relative to what else is available to work on. A High priority bug may be less important than a new Feature.
- From my experiences, Priority does not lead decisions. It follows.
- Tester: “Per our process, we will only patch production for High priority bugs”.
- Stakeholder: “Well, obviously we need to patch production today”.
- Tester: “But said bug is only a Medium priority”.
- Stakeholder: “Then change it to a High”.
- IMO, Priority is all but useless. The more High priority active bugs one has, the more diminished it’s label becomes. A better label is “Order”, as in let’s rank everything we can work on, from most important to least important, where each item has a unique ranking order.
5 comments:
Subscribe to:
Post Comments (Atom)
RSS
Thanks for the post.
I would like to see the template of the microsoft TFS Bug Template u are use.
Can i have the screen shot of it.
So u keep the Priority as "Medium" every time when u log the bugs.
And then the report is send to "Stakeholder"
as per him,the priority might change and send to development team. (this is what u follow this procedure?)
If the interaction is between the testers and developers - what should happen in this scenario?
What all priority levels should be there while logging ?
Hi Eric,
I've got a similar take on priority to you, but I'm more relaxed about the testers on my team setting the priority when they submit a ticket.
Most of the time we all leave the priority at default P3. If one of the team feels strongly, they can change it. Because this is relatively rare it is a useful piece of data in triage. By convention we justify higher priorities in the ticket body - this includes noting information that would help a stakeholder decide on the priority for themselves.
Hi Eric,
Whilst I 100% agree that with you in regards to the possibility (and futility) of marking everything as "High" there are still benefits to having a priority field completed by the tester.
For us, priority relates more to the impact the bug has on our remaining testing effort.
So if a bug prevents us from testing large areas of functionality then it is a high priority whereas if it can allow us to continue then the priority is lowered.
I don't know if you're coming onto severity next but we tend to use that to indicate the damage the bug will do if it goes live (if it isn't live already).
You can have a low priority, high severity bug and vice versa but we find it is the combination of the two that is used to help developers prioritise what is fixed first.
Phill, I just did a post on Severity. Thanks for the transition.
I don't see much harm in what you're doing with Priority or Severity as long as it is working. Just make sure it is working, as opposed to just thinking it is working.
In other words, do your programmers really decide which bugs to fix first by looking at a Priority attribute? Or do they already know before they query by Priority? Maybe the testers are verbally saying, "Hey man, this is a blocking bug, please fix it next". Or maybe the programmers are starting with the bugs that can be fixed within the source code they currently have checked out.
If you find, people are making the right decisions without Priority or Severity, then set us free... Ahhhhhh, one less thing us testers have to worry about...
I totally agree with you, this should NOT be our responsibility.
I worked with jira database and the Priority was auto-updated based on Severity and Probability, which I had to choose.
But after that, my team leader modified it, and sometimes, the developer...that's why I think it's better that the development team should set this things, according to their own pleasure. :)