Most products require some degree of testing to confirm proper assembly, function, and performance. Many products require significant testing, stress screening, calibration, and record keeping to meet the market requirements.
No matter where your product falls in this spectrum of test requirements, the best way to determine the scope and timing of testing is by analyzing the risk of defects shipping with the product. A Process Failure Mode and Effects Analysis (PFMEA) is a tool to quantify the risks and help determine when to test and how much to test.
There is a balance to maintain between testing and the risk of a failure in the manufacturing process. It is axiomatic that you may not knowingly ship defective product; the damage to the customer relationship and your reputation may be permanent. That said, it is not practical to test for every conceivable failure, so you must have some process to judge the more likely failures and ensure they do not escape detection. If you miss one, it is important that you implement a corrective action to your process so that it doesn’t happen more than the one time. The other aspect of this issue is to decide when in the process to detect the failure.
If the detectability of the fault is likely – test processes will catch the failure before the product ships – then the issue is one of manufacturing cost. If a failure detected at the end of the manufacturing process (e.g., Final Test) is easily fixed because the part is readily accessible and takes little effort to remove and replace, then it does not make much sense to test the part at an earlier point in the manufacture. Adding a test step adds to the cost of manufacture, so if is beneficial to eliminate as many steps (both assembly and test) as possible.
However, if the part requires significant disassembly to replace it – and significant effort to re-assemble the product – then the cost of a sub-assembly or in-process testing of that component may be warranted. The tradeoff depends on the risk of a failure times the cost of fixing the failure, compared to the cost of testing for that failure in all the products, even the ones that will not fail.
For example, if you estimate that 1 of 100 (1%) of a component is defective, and it costs $100 to change that component once the product is fully assembled, the cost of the failures is 1% x $100 or $1 per product. If it costs $0.50 to do an in-process test to remove the defective components early, that test pays for itself quickly. Just for scale, a 1% defect rate in a component is a big deal and not something to tolerate. Note the cost of the component is not included in this calculation; we are assuming that the component will be returned to the supplier for analysis and corrective action (different subject) and replaced. The transactional cost of a defect is significant, but it doesn’t matter when the defect is discovered.
The above assumed that the “detectability” of the defect was likely. That isn’t always the case and can significantly increase the risk and cost of a defect. If later testing does not determine if a component is functioning properly, then there is a risk the product will ship with that defect. If the consequences of that failure (the severity) are high enough, the costs to sort out the mess can be considerable in both cash and goodwill with your customer. If the risk and likelihood of the failure is high and it is not detectable later in the process, it will be necessary to devise a test for that component at a point in the process where it can be tested more easily.
We have seen many different test procedures for products that we build, and it looks like many of the in-process test points are derived from issues that have come up during the Beta prototype development. This is good information and good judgement, but it would pay to evaluate the necessity of those continued tests before imposing them on higher volume manufacturing. The Beta test process is great, but it mostly focuses on design verification testing, not manufacturing process testing. Some in-process testing may be redundant, and other in-process testing may be required.
Consider two assemblies sitting side-by-side on a bench. Which one has been tested and which one has not? If there are multiple tests to perform (e.g., functional test, calibration, stress screening, Hi-Pot/Ground Bond), how can you tell which assemblies have passed which tests? There are ways of positioning assemblies – like queueing them near a test station – to make it clear, but as manufacturing volume changes and failures are detected, it can get very confusing very quickly.
For low and medium volume complex products, the method most likely to work is a Test Status Checklist, where each test has a separate row in a table, with an identification of the test, a place to record data, test limits, a place to indicate status (blank for “not run yet” / Pass / Fail), date and technician initials. This document can be a physical paper which travels with the assembly, or an electronic record linked to the assembly by a serial number.
This Checklist can also contain the assembly configuration – Serial Number, Network Address, Serial Numbers of sub-components, calibration coefficients, and other data that may need to be saved about the product.
This Test Record can be the basis for a file on each product that has shipped. In the medical device world, it would be a Device History Record (DHR), but the same idea is useful in other industries.
The DHR can also contain references to sub-assembly records for components on the assembly, incoming inspection data on components or other data deemed necessary. If necessary, you must be able to trace all meaningful parts back to their origin and trace a batch of parts to all the product serial numbers that they are installed.
The records and the design of the forms is part of the manufacturing process design and is driven by the requirements of the market for transparency into manufacturing and traceability. The data maintained in these records is also a crucial input into how well the manufacturing process is under control and informs decisions on improving the process for better quality, improved delivery, and lower cost.