Hey, the product doesn’t work–blame test!

Ever seen the movie where the wild-haired designer looks up from her or his laptop only to be greeted by a stern-faced production manager who says, “Your new design is failing at final test”?  And the designer responds, “Why are you talking to me.  It’s a test problem.” All the test engineers out there are grousing, “Seen that movie? Heck, I was the guy in the red shirt who died in that movie.”

No, of course they don’t make movies about engineers of any stripe, but the point is still the same…

It’s an all too common problem, blaming the person who finds the problem for the problem.  Since a good production test process–or validation test for that matter–is supposed to find problems and reject parts that do not function properly, it’s small wonder that such test processes detect problems.  Test engineers are supposed to design tests that identify failures.  It makes no more sense to blame the test engineer for identifying a design fault then it does to blame a doctor for identifying an illness.

Fortunately, after everyone gets “plumb tired of all that bell-fired finger-pointing” (old Zeb is looking over my shoulder and threw that there Zebulon-ism in…) there are proactive solutions.  Investing in a rigorous design validation testing (DVT) program should detect issues before they get to the production floor.  Further upstream, a Design Failure Mode and Effects Analysis (DFMEA) can help predict what might fail, the better to focus engineering and testing efforts.

And as for all those design engineers out there, myself and our design team included–best we take a test engineer out for lunch now and again. Because even with the best engineering rigor, the most through validation efforts, mistakes will still happen and we’ll be once again be glad that the test guys caught yet another problem before our customers do.

And no more undue blaming of test. Blame Murphy instead.


Leave a Comment