Most bug reports include Severity and Priority. On my team, everyone is interested in Priority (because it affects their work load). Severity is all but ignored. I propose that testers stop assigning Priority and only assign Severity.

Priority is not up to the tester. It is usually a business decision. It wastes the tester’s time to consider Priority, takes this important decision away from someone more suited to make it, and finally, it may misguide workflow.

Bugs without Priority have to be read and understood by the customer team (so they can assign priority themselves). This is a good thing.

What about blocking bugs, you ask?

Some bugs are important to fix because they block testing. These bugs are best identified as blocking bugs by testers. They can be flagged as “Blocking Bugs” using an attribute independent of the Priority field. Think about it…if BlockingBugA is blocking testing that is less important than other, non-blocked testing, perhaps BlockingBugA only deserves a low priority.

Tell me where I’m wrong.

11 comments:

  1. Ken said...

    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.

  2. Jesper L. Ottosen said...

    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 :-)

  3. Calkelpdiver said...

    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.

  4. Roman said...

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

  5. Alex said...

    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.

  6. Yaniv Iny said...

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

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

  7. Joe said...

    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.

  8. Basim Baassiri said...

    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

  9. Dutch Tester said...

    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.

  10. Michael Bolton http://www.developsense.com said...

    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.

  11. Assaf said...

    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.



Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.