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