Imagine creating a product that couldn't be tested before shipping to a customer.
Now, I realize just turning it on or trying it in a real-world application to see if it works is a fundamental practice that all companies use to verify product readiness. After all, if it doesn't turn on, or doesn't fit, or it doesn't open, or it doesn't begin to function at the most basic level as designed, it probably won't make it passed final inspection.
But, as we all know, most products require a multitude of testing operations to verify not only initial functionality, but also conformity to required operational, regulatory, and environmental compliance mandates. Testing provides the assurance that the product is performing as designed and is customer and market worthy.
Early on in the R&D process, the design engineer, working with test engineering and software assurance, should have developed a testing methods document that includes the associated list of relevant test equipment that will be needed to perform each type of the tests.
This document becomes the fundamental guide in assisting the engineers in determining the test points needed on the printed circuit card, the test processes that can be automated for Automatic Test Equipment, ATE, the connectors to add to the product's design that will be the interface between the Unit Under Test, UUT and the test equipment, and the diagnostic software that needs to be written. This test process is known as "Design for Test," DFT.
Pay me now (or later): A thorough design-for-test methodology
can save money long term and ensure product success.
Each major area of testing requires sub-levels of consideration to ensure as close to 100 percent test coverage on the individual assemblies and ultimately the top level product. At the circuit card level, the designer will want to consider not only what has to be tested, test vectors, but also how much can be tested and how those test sites can be accessed.
For in-circuit testing, ICT at the board assembly house, the designer must leave room for the "bed of nails" used in ICT to contact each pad where the test data is to be gathered. Bare PCB testing can check for open and shorts, but functional ICT testing is performed under power where test data is fed to ATE gear programmed to gather the specific test point parametric or pass/fail status.
Connector placements may pick up test points where a probe is unable to reach. This is especially true with Ball Grid Array packages where the IC solder ball connections to the printed circuit card are on the underside of the integrated circuit package. A well-placed connector designed to take signal or bias data from traces to and from specific BGA inputs and outputs will make it possible to determine if the BGA circuit is working or not. If there is no way to isolate and test a 576 ball package, then the technician cannot determine if a problem encountered on the board is due to a BGA problem or some other component issue.
Knowing what circuits can be tested using JTAG will also assist the test fixture design. Adding components like EEPROMS and I2C Buss chips will add more test capabilities. Software scripts embedded in PROMS can run diagnostics or start a test sequence. Often times, testing harnesses and custom test fixtures facilitate the testing processes at various stages of assembly.
If a board or product is not designed with DFT in mind, then trying to play catch up and guarantee maximum test capability coverage is a nightmare.
Technicians are forced to use shotgun repair techniques, meaning they just start swapping components until the board works. Last time I checked, the assembly house charged $50 per BGA to remove and re-ball. Custom SMT solder screens have to be made to replace a BGA component on the board. If there are a number of BGA ICs on the board with no accessible test points, then the nightmare can turn into a full-blown production horror novel. Always include DFT into product concept and design review meetings.
Someone should always be asking, "How do we test it?"