Greetings,

We’re enjoying the last weeks of summer but looking forward to a busy fall season. I’m excited to announce that we will be repeating the Best Practices for Effective Test seminar. Join us at the end of October in Rochester, Syracuse, Albany or Buffalo. Seminar details, including dates, locations and how to register can be found on our website.

When we presented in the Spring, one of the highlights of the seminars for me was the attendee participation and interaction. Discussion about real life challenges were interesting and added real value for the people asking the questions as well as the ones providing suggested solutions. I’m hoping to increase participation even more this year by starting each seminar with a roundtable breakfast. If you have a question or topic you’d like to see covered, please feel free to send it in.

In this month’s issue, I will focus on one common challenge that confronts every test engineer: the belief that test adds no value. We all have had to respond to this concern and address the issue with those in our respective companies that pay for test systems. How would you reply? I point out some ideas in this issue.

This issue is especially relevant if you are embarking on an upgrade or creation of a product test system.

Over the next months, I will overview some of the ways we try to accelerate the payback for test.

Thanks for reading!

Jim Campbell
jac@viewpointusa.com

A common thread we at Viewpoint have seen over the years is the belief that product test is a cost burden on the company. I personally have heard from many people who are quick to point out that, if everyone upstream from the test system did their job right, products would just work and test would not be needed.

This philosophy is embedded in the thinking of Six Sigma: reduce variations to zero, so no faults occur. However, in the real world producing faultless product is rarely a reality and perfecting production methods and component suppliers would be ultimately MUCH more costly than spending for a product test system to detect bad product. It is our job as test engineers to help find the balance between producing faultless product and justifying end-of-line test systems. What should we consider to reach this goal?

Read more...
 

Challenge: if you are replacing an existing test system, before you implement the new system, measure some key performance indicators (KPIs) on the old system and then do the same on the new system.

Then you can analyze if the new system benefited the company. Possible KPIs are:

• Test cycle time

• Floor space usage

• Annual maintenance time

• Usage count of design team reviewing of test results per year

• Capital equipment costs (note purchase dates to allow inflation adjustments)

• Results reporting time (form filling and form printing for unit\batch\lot)

• Test data management time

• Usage count of quality, Lean, or Six Sigma teams in reviewing test results

• Amount of code reuse from product design and reliability groups (VI or function count)

I think it would be interesting to conduct a study of KPIs used by those responsible for test. The goal would be to share KPIs deemed beneficial for justifying a new test system. Would this collection be something that you would be interested in? I’m open to ideas so email me, even if you just want to let me know you’re interested in participating.

In 1944 the first programmable digital computer was made in the U.S., produced by the joint effort of Harvard and IBM called the Harvard Mark I. Although the term “bug” had been used since at least 1889 to refer to a defect, a programmer of the Mark I, named Grace Hopper, coined the term “debugging” when she found a dead moth that was blocking the reading holes in the paper tape.

Photo Credit: www.computersciencelab.com

To register, visit ni.com/training
or call 585-475-9555.