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:

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?

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.

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...

Who am I?

My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.