"So, is bug 123 a blocker?"
Well, that's an interesting question. Like many organizations, we have guidelines for this sort of thing:
- if it results in data loss or corruption, it's a blocker
- anything that makes the system crash is a blocker
- anything that's going to create excessive support calls is a blocker
It's more subtle than that, though. If a blocker will make you miss the release date, and you have revenue riding on that release date, is it still a blocker? How about if it won't affect the customer providing the revenue?
Ultimately, for each bug the real way to understand if it's a blocker is to ask:
- who cares?
- what will this entity who cares do if they hit this bug?
- what are the consequences of fixing this bug?
- which is worse - what happens if the bug occurs in the field, or what happens if we go ahead and fix the bug?
If it's worse to fix it, then it's not a blocker. If it's worse to hit it, then it's a blocker.
Ultimately, whether an issue is a blocker depends on who your real customer is and what they will do in the "fix it" scenario and in the "don't fix it" scenario.
* An aside for the (quite large) school of thought that says testers provide information and do not make these decisions: well, I'd rather not get into that argument. After all, we're not talking about who makes the decisions here; merely about how the decisions get made.
No comments:
Post a Comment