Friday, October 31, 2008

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.

No comments:

Post a Comment