This is a summary of feedback I received recently from experienced test and product engineers in LinkedIn on how test developers could help product and sustaining engineering debug issues when a product is released into production. Often of course after release the test engineer is busy on the next family of products and will have little time to help with yield management issues on older products. Thanks in particular to Chris Jakubiec, Jeffrey Ho, Mustafa Jaffer, Doug Teeter, Rob Brodner, David Cutler, Robert K. Morgan, David King, Jerome Auza and Satish Bansal for their inputs. Here is the list of recommendations which should be educational for newbees in test development engineering but also a refresher and hopefully a thought-provoker for more experienced engineers:
– Test names that make sense
– Good documentation for production programs including for power supply voltages used for each test, applied timing sets & for a functional test, the vector used for each test
– Bins should be consistent across products in a product family
– Make sure to datalog the first failing vector cycle when a functional test fails
– Test conditions read automatically and stored in the datalog where possible
– Good schematics for any boards or jigs
– Correlation (golden) units provided with gauge R&R results showing low standard deviation and results well within specification
– Additional boards and sockets/probe rings provided
– Run and review test stability results concurrently with the product and sustaining engineers for a full understanding of potential marginal or erroneous performance issues
– Interface hardware designed to withstand the rigors of volume production test
– Unique test numbers so as not to confuse a Yield Management System (or data analysis software), especially since some testers which generate STDF can generate non-unique test numbers, but that possibility can be more than likely eliminated by the test engineer
– Consider your Continue/End on Fail strategy especially when parallel testing, to generate information which could be useful for debug. There may be no measurable effect on test time in multi-unit test setups.
Comments welcome and I’ll update again if any more inputs received in the LinkedIn groups.