Comments on Test This Blog - Eric Jacobson's Software Testing Blog: Don’t Ask The Tester For Bug Priority

I tend to agree with that. About blocking bugs. I...

2010-05-11T11:49:22.967-04:00

I tend to agree with that.

About blocking bugs. In some systems, a blocking block in one testing path is not necessarily blocking you from exploring other paths, so you encountered one wall, "move" a bit and proceed in another direction.
Also, blocking bugs should be divided into two. 1. Blocking testing efforts and 2. Potentially blocking costumer (Show stoppers, as we call them) from doing their work.
Number 2 will obviously have a higher severity than number 1.

You're on the right track about priority, whic...

2010-01-15T03:20:28.540-05:00

You're on the right track about priority, which means assigning a precedence for when the work should be done. That's work for the managers.

Now all we have to do is to learn how to be very, very cautious about severity—the meaning and significance of the problem—which means, in essence, assigning a precedence for why the work should be done.

It's not clear to me that the tester is the best person to make this decision either. To a great degree, from the tester's perspective, the significance of the problem is only a guess. We can observe effects in a particular place at a particular time (the test lab), but how that will play out in the world is subject to a lot of inference. Yes, it's a crash, but it's a crash in a very narrow set of conditions, on a particular model of machine, causes no data loss, and has a workaround. Plus a one-byte fix will solve it. Critical problem or not? Another case: Yes, it's only a cosmetic problem—just a little typo—but tell that to the customer, the Cleveland Pubic Library.

What I'm trying to get at here (with these alarmingly trivial examples, I admit) is that there are technical and business considerations to our notion of severity, and some of these notions may be outside of the tester's awareness. So we should make it clear that our perspective on severity is a first-order evaluation, and should not be considered final. I'd argue that ultimately, the product owner decides that too.

There is at least one case where the tester's evaluation of severity should be taken very seriously indeed, in my view: something that blocks testing is a very severe problem with very high priority, because it
blocks our ability to discover problems that may have devastating customer impact.

There's a good discussion of this in Perfect Software (and Other Illusions About Testing), by Jerry Weinberg

---Michael B.

Priority can often be set based upon your Product ...

2010-01-14T11:00:13.933-05:00

Priority can often be set based upon your Product Risk Analysis. Mainly because your PRA must always be the driving element in all your testing activities. Of course the 'user' decides at the end.
But for a tester a bug has the highest priority when this bug is blocking for further test activities.

Where I work we use JIRA for issue management and ...

2010-01-14T10:20:38.927-05:00

Where I work we use JIRA for issue management and Grasshopper for agile planning. We were using a custom field Development Priority that was set by me (being QA). Later we renamed development priority to requested priority to describe urgency. We let grasshopper ability to order bugs/tasks do the development priority. We treat severity as impact to the user i.e. can the user complete the desired task. If no work around exists, its a blocker.

hope this helps

You are absolutely correct. Priority indicates in...

2010-01-14T09:41:04.906-05:00

You are absolutely correct.

Priority indicates in what order bugs should be analyzed/fixed (if at all). That's not usually something the tester gets to decide in isolation. In my shop, all bugs are assigned a default priority when the bug report is written. The project team later reviews bugs reports and modifies priority as needed.

As far as blocking bugs, Bugzilla has a Severity called "blocker" by default.

Agreed. Priority is a business decision more than ...

2010-01-14T01:51:23.639-05:00

Agreed. Priority is a business decision more than anything else.

especially liked this:
"Bugs without priority have to be read and understood."

I agree so much that I track/assign neither. No f...

2010-01-13T20:39:39.310-05:00

I agree so much that I track/assign neither. No features are released if they aren't done. If there's a bug, they're not done. If a bug is found in production, it gets put on the backlog of features that the customer prioritizes.

Absolutely right! I have nothing to add. Severity...

2010-01-13T16:06:01.185-05:00

Absolutely right! I have nothing to add.
Severity is the only Thing a tester can judge from his expertise. Also agree on Blockers!

You're not wrong, actually right on target. T...

2010-01-13T15:29:19.346-05:00

You're not wrong, actually right on target. The team as a whole needs to set Priority. But along with Severity you need to weigh in the Risk/Exposure of the problem in order to set the Priority.

Think about that one.

My team usually goes with Severity (business impac...

2010-01-13T15:04:18.075-05:00

My team usually goes with Severity (business impact) only. Priority is optional, but usually a (test) management decision - this bug is more important than that one.

Blocking bugs usually gets a high severity also. I've contemplated that from time to time. Flagging them with a separate attribute - good idea. But actually if bugA is blocking bugB, and bugB is business critical, then yes so is bugA.

And then you're right, thank you :-)

AMEN! Our team's practice is that severity i...

2010-01-13T14:37:05.816-05:00

AMEN!

Our team's practice is that severity is the level of technical impact while priority is the level of business impact.

The tester may set an initial value to priority, but ultimately the final decision on priority is owned by the business partner.

Also, we try to set definitions for severity that leave little room for debate, while the definitions for priority are more flexible and responsive to business need.