Friday, October 17, 2008

The Five Why's and Testing Software

Toyota was able to eclipse the makers of American cars in part due to its production and development systems.  The system has been popularized under the rubric of "Lean" techniques.  Among the tenets of the Lean advocates is asking the "Five Why's."  These are not the W's of journalism:  Who, What, Why, Where, and When?  They are not specific questions even.  Asking five why's means asking why 5 times.  Why was the production of cars down?  Because there were missing screws.  Why were there missing screws?  Because the production robots were bumping them.  Why were the robots bumping?  Because the programming was faulty.  Why was the programming faulty?  Because the programmer didn't take into account a metric->English conversion.  Why didn't the the programmer consider conversions?  Because... 

There is no magic in the number 5.  It could be 4 or 6.  The importance is to keep asking why until the root cause is understood and fixed.  Fixing anything else is just alleviating the symptoms of a deeper problem.  Not solving the root problem means it will likely cause other problems later and more time will be wasted later.

How does this apply to testing?  It goes to the core of the role of test in a product team.  Think about what happens when your team finds a bug in your software.  What do you do?  Hopefully someone on the test team files a bug report and either the tester or the developer root cause the problem and fix it.  This usually means determining the line of source code causing the issue and changing it.  Problem solved.  Or is it?  Why was that line of source code incorrect in the first place?  We rarely--if ever--ask.

What if we began to view our role as testers as trying to eliminate bugs from the system instead of from the source code.  In that case we would be asking what coding techniques or early testing systems the team could employ to stop the bug from entering the source code at all or at least detecting it while the code was still under development (better unit testing might be a solution in this category).


  1. the 5 whys are part of the whole kaizen practice. I am always slightly amused and dismayed that they got the Idea from the Americans( like Deming)  and used it to displace America in Manufacturing.
    I'm not much of a coder but I'm interested in seeing how you apply this to coding.

  2. Grant Holliday on What's the difference between tf workspace /delete and tf workspaces /remove? Shai...

  3. This is why the Terminator was so effective ...
    J.C. - "You can't just go around killing people?"
    Term - "Why?"
    J.C. - "You just can't!"
    Term - "Why?"
    J.C. - "You just can't, alright!? Trust me on this."
    Term - *stare*
    Hmm, maybe he didn't get enough why's in.

  4. You know, kids do this automatically.  What I found out was that if I kept actually answering instead of cutting it off with "Because I said so" that I found that sometimes I really didn't have a good answer.
    I decided at that point to (try to) always have a very good, justifiable reason before asking my kids to do things.  If I couldn't explain it then I shouldn't be asking.

  5. I read (in a book somewhere) a nice extension of "the five whys": Any failure of a (reasonably complex) application is usually at least two bugs.  
    - The program crashed because it didn't handle a NULL data field
    - The program would fail to initialize the data field when reading an old version of the record
    - The periodic maintenance procedure fails to update records with non-unique account names
    - etc.  
    This is a little more interesting than just drilling through 'why's because each of these answers is itself a bug that needs to be tracked and fixed.  However, as soon as any one of them is fixed, the crash will stop.  I sometimes think that half of our code is the correct handling of the "impossible".
    "We rarely--if ever--ask."  Do you just mean from the testing side?  To me, that's a mandatory part of making a fix.  I certainly always ask during a code review of such a change.