Why Why Why Why Why?

"Why did you miss that?"

I imagine you have heard that question more than once, regardless of whether you test, write code, manage a project, or run a company. Something unexpected happens and now the powers-that-be want to know how you could possibly not find so obvious a bug, or forget to handle so obvious a case, or neglect to account for so obvious a project risk, or fail to consider so obvious a business issue.

Most software today is so complex that finding every last defect is effectively impossible. Most software today is so complex that writing it completely correctly is effectively impossible. Most software projects today are so complex that identifying and mitigating every possible reason they might go awry is effectively impossible. And most software companies today are so complex that consistently keeping them on the right track is effectively impossible.

Even if doing these things was possible, you almost certainly wouldn't have time to handle the additional work which would result. I don't know of a software team that has sufficient resources to handle everything they *do* think about, let alone everything else they haven't considered! Triaging and prioritizing which test cases to execute, which code to write, which risks to manage, and which issues to worry over seems to be the rule of the day.

Which is all fine and dandy until one of those items you missed out, either intentionally or out of ignorance, comes back to haunt you. And the powers-that-be descend in droves to ask:

"Why did you miss that?"

I personally do not worry about missing tests, code, risks, or business twists. If I don't miss any, great! When I do miss one, I identify why I did:

• I go back through my Work Notebook, which I populated with everything I saw, heard, did, and thought about as I went about my job, and determine whether I did, in fact, miss the item, or whether I triaged it away, or whether I willfully disregarded it.
• I Five Whys my way from the problem to its root cause.
• I ask my colleagues how they account for similar matters.
• I attempt to understand why this case seems to require special handling.
• I look through my other projects and determine whether I missed similar problems there as well.

And then I modify my processes to help me not miss such scenarios in the future.

This is what I do when I miss a bug, or an edge case, or a project risk, or a business issue. What have you missed today? What are you going to do about it?

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.

Comments

• Anonymous
  June 14, 2008
  The comment has been removed