Balancing the cost of test with customer-driven coverage requirements.
One of the challenges many companies face is balancing the cost of test with test coverage requirements. The test engineering team in SigmaTron International’s Suzhou, China, facility uses Lean principles to achieve that goal. In all cases, test strategy is aligned with each customer’s goals for optimum test coverage, and the solution is the result of a collaborative process.
The strategy focuses on four main areas:
Keep it simple. The more complex the programming language and development environment, the more time test can take. For example, when C++ is used, the program must compile it with the overhead, which adds time. The Suzhou test programming environment is focused on delivering test coverage customers require at the lowest possible cost. The goal is to load data in and read them out as quickly as possible.
The team’s formula is “keep it simple and focus on what is needed.” Programming is done utilizing C# and Basic Language, using RS232, USB, GBIP, etc., to communicate to test instruments, read back the test data, analyze data, transmit the test results to the terminal and then store the test results in the network database. The test engineering team is able to design programs from functional specifications, or even create a simple functional test from a schematic alone.
Eliminate excess handling. In a high-volume test environment, load and unload time can add significantly to cost of test. Inefficient handling can also increase the potential for defect opportunities. For example, clamshell hold-down fixtures or bed-of-nails fixtures are preferred over connector-based test, since plugging and unplugging can weaken the connector and exceed target test time.
In one case where the customer originally supplied a connector-based fixture, the test time was one minute, and the handling time was six minutes. Test engineering designed a clamshell hold-down gate with a pogo pin to establish contact with the connector, along with a probe plate that permitted the tester to be actuated from either top or bottom. They also modified the programming to make it more stable, as the test program was not measuring voltage at the right time. The result was still a one-minute test, but handling time was reduced to 30 sec.
Standardize and automate where practical. The team uses a standardized functional test platform and can design equipment that does everything from simple functional test to a program, test and pack station. Optimizing a standard test platform to perform the right mix of activities for customer requirements has three advantages. First, it minimizes defect opportunities that could occur in segregated programming or serialization by grouping them in a single test station.
Second, it simplifies maintenance activities. Finally, it provides some level of redundancy should a tester require unscheduled maintenance.
Data collection at each test station is integrated with the company’s proprietary shop floor control system. Each product carries a barcode with a serial number to facilitate this tracking. This is particularly important to customers requiring genuine first-pass yield data.
This focus on data collection is one reason the test engineering team prefers to design test fixtures even when utilizing customer-supplied testers. They typically design a clamshell press-down automated fixture that will access test points and set it up to make sure all necessary data are stored in the database as units are tested. Comparatively, customer-supplied fixtures don’t always have this capability built in. In these cases, the test engineering team can utilize an interface program with the tester’s computer to add the data collection capability.
Minimize system-generated variation. While most failures in test are driven by issues with the product, in high-volume production failures can also be driven by tester or software-driven issues. Testers that exhibit this type of system-generated variation increase the cost of test and increase the time required to troubleshoot the root cause of test failures.
One driver of the facility’s strong internal test development capability was the occurrence of difficult-to-replicate failures in customer-supplied test equipment. The test engineering team found that many customer-developed testers had design issues or simply weren’t up to the rigors of volume production. The problem is typically that good contact isn’t being made with the unit, or the test program isn’t measuring the signal at the right points. This causes intermittent failures that can be hard to replicate. When there is a trend of units that fail a test, but pass the second time, that is often a clue there is an issue with the tester, rather than the unit under test. In those cases, fixtures or jigs are fabricated to improve the contact and see if that changes the trend. If it doesn’t, the issue is normally software-related.
For example, in a project where functional test was performed at the end of the line and the customer was performing system test at its factory, units that passed functional test were failing system test. The test engineering team worked with the customer team to understand the details of the failure to replicate it. In this case, the signal in the system test wasn’t stable and required design modifications. Most test programs take a signal reading a couple times during the test and average the results. If the signal isn’t measured at the right time, it causes a failure. Reprogramming the tester to optimize the timing of signal measurement eliminated the problem.
This Lean collaborative approach to test program development and test equipment design has been successful enough that today nearly 80% of the facility’s projects utilize internally designed fixtures and/or functional test equipment. In some cases, customers have asked the test engineering team to fabricate duplicate test sets and fixtures for their factories.