Who Cares?

We're in the throes of a release cycle, which leads to all sorts of fun conversations, many starting like this:

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