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.
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- 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.
My other passion is woodturning.
Test blogs I try to read
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.
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 :-)
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.
Absolutely right! I have nothing to add.
Severity is the only Thing a tester can judge from his expertise. Also agree on Blockers!
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.
Agreed. Priority is a business decision more than anything else.
especially liked this:
"Bugs without priority have to be read and understood."
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.
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
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.
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.
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.