Use Multiple Software Test Techniques
Use multiple software test techniques
So, what can we do? Well, first, remember that software testing cannot save us from this problem. However, there are many different software testing techniques. Each type of testing can expose a different set of defects. Testers must use different test techniques, test data and test environments for different bugs during different levels of testing. Each technique, each set of test data, each environment and each test level filters out a different set of bugs. There is no "one true way" to test software.
Now, I'm not saying that Toyota believes in a "one true way" to quality. Toyota learned quality management from Joseph Moses Juran and William Edwards Deming-heroes in the pantheon of quality. Juran and Deming knew much better than to believe in a single magic bullet for quality. However, as we saw from Toyoda's comments, he did believe too much in testing. In addition, I suspect that Toyota, as a company, believed too little in integration testing-and perhaps too much in vendors.
Here's the problem: When complex systems are built from many subsystems, and some of the subsystems are produced by vendors, risks can go up and accountability can go down. It's not that vendors don't care; it's that they can't always foresee how their subsystems will be used. It's not that the people won't take responsibility-though that happens. It's that, when multiple subsystems are at fault, neither vendor wants to take all the blame.
So, understand, measure and manage the quality assurance process for such systems from end to end-including vendor subsystems. After all, the user drives just one car, not a dozen, and there is only one brand on the grill-and this is true for your data center, too, isn't it?