test plan

You are currently browsing articles tagged test plan.

“Is there such a thing as a stupid question?” almost certainly answers itself: of course there is!  We read them all the time in the blogosphere;  kids ask them; strangers at the grocery store ask them. Of course we never ask a single stupid question ourselves–but that’s the topic for a psych blog, not an engineering one.

In the engineering world there are of course still stupid questions, or at least ones that waste time, promote discord or camouflage the real issue.  But good engineers–smart engineers–know when it is the right time to ask stupid questions. Like at the start of a project? Like when a spec isn’t clear?  Like when time is of the essence and we need to ship today and it’s better to get it right than do it twice. Again this can go the other way–too many questions slow everyone down and a deadline is missed.  A balance is needed (see our blog on Lagom, the thoroughly excellent Swedish word for “just right”), and what is really needed are smart stupid questions.

We had the kickoff meeting last week on a production test development project, a project on a near impossible time schedule with some real challenges.  We sat with our customer  (see our blog on Great Customers–this is one of them) until it got dark, asking a lot of stupid questions, mostly of the smart stupid subspecies.  Stupid questions that allowed us to get up to speed faster; stupid questions that clarified the intent behind the spec; stupid questions that filled in blanks; and stupid questions that (hopefully) will keep us from making some of mistakes that were made to date (is there ever an engineering project without mistakes?  Ask Murphy.)

Result: we have a test plan already; we’re  writing code already; we’re on schedule, or maybe even a tad ahead (don’t tell Murphy).  Yes we asked some stupid questions, but as our customer told us, “There are no stupid questions.” Not true, strictly speaking, but in this case it worked.

Chuck

Tags: , ,

Ever ventured unwittingly into the shadow world of NoTest? It’s the hazy utopia where the ivory tower types proclaim that if the design is good and manufacturing is good then why test.  Sometimes this even came up in a snarky way, back when I worked in an integrated contract design and manufacturing (CDM) environment, as in “You did my design and you’re going to manufacture it, so then you don’t need test . And oh by the way take the test line item out of the open book pricing I made you provide.”  Followed by a sneer, or at least I envision a sneer in my memory when I think back unfondly on those days.

Of course doing without test in the real world is, well, fantasy.

Don’t get me wrong I’m a huge fan of doing a solid design, employing six sigma techniques where cost effective, and conducting serious design validation testing long before production release.  I’m also a fan of spending the effort needed to productize a design–get it ready for production and get production ready for the design.  But despite best efforts and intentions, I am also a believer in both Murphy, he of that oft quoted Law, and also in statistics, which basically say that even with a robust design and a low DPM (defect per million) manufacturing yield loss there are still product that will fail, and its better to know about a failure sooner rather than later.

Of course the level of test absolutely should be commensurate with the product robustness, yield issues, and the total cost of field failures (which while high are not infinite) including impact on brand, returns, customer satisfaction.  And while in reality NoTest is an extreme that is rarely ventured, many companies do neglect developing and implementing a production test plan that is as robust as their design methods and production practices. Often times this is due to lack of understanding of how test works; sometimes its part of the “beat up your contract manufacturer,” and all too often it’s just part of the productization chasm that widens with time as design teams and their manufacturing counterparts drift further and further part. (for more on this see our productization blog on the chasm analogy, http://zebulonsolutions.com/productizationblog/?p=41).

The right solution is really to put the same effort into making sure your test plan is robust as you do for design, marketing or any other function.  Start with requirements, look at tradeoffs, come up with a draft plan, scour it for cost effectiveness and get buy in from the cross functional team.  Make sure the risk / reward equation is properly balanced, and, as my Swedish friends would say, make sure the amount of test is lagom–neither too much nor too little.  And avoid the sirens as they lure you toward the shadowy land of NoTest.

Chuck

Tags: , , , , , , , ,