PCB in circuit tester design
Yes, this sort of thing comes up regularly. We have settled on a system that works pretty well for small boards. Here is one example:
The top part is hinged at back and swings up. You then place the board to test in the cradle for that purpose:
What you can't see in that picture are the pogo pins that stick up from the tester under the board. When the lid comes down, it presses on the board at carefully selected points. This compresses the pogo pins a bit so that they make reliable contact. Pads were designed onto the bottom of the board under test for just this purpose.
When the lid is lowered, a little latch swings over part of the lid arm:
This does two things. First, it locks the lid in place keeping the pogo pins compressed a little. Second, it releases pressure on a microswitch. This switch is wired to the processor on the tester. It is used as the signal to start a new test.
The general design is canned, but the details are not. The pogo pins are held in place by the thick plastic piece screwed to the test board. This has holes in it matching thru-hole pads in the test board below. The pogo pins holders are placed into the holes in the plastic from above. A small piece of each holder protrudes thru the pad in the tester board, and is then soldered from the bottom.
This is a convenient way to make electrical connections to the pogo pins. They are just single-pad thru-hole components from the tester board's point of view.
The tester then contains whatever circuitry you need to test the board. This usually includes controllable power supplies with voltage and current signals going into the control micro. In this example, part of the test procedure was performed on a PC, and the tester communicated with the PC via USB. A PIC 18 was used to run the tester.
The test procedure includes programming a PIC in this case. For that we usually start with our USBProg PIC programmer circuit, but use a larger PIC so that there are a bunch of pins available for the test function. We even added 16 reserved commands to the official PIC programmer protocol to support testers that are USBProgs with added features.
Once we have the test circuit board mechanical details, we send them off to a mechanical engineer that we work with. He then takes the general tester design and adds the details for that specific tester. He designs the bottom plastic part, the lid, the exact mounting holes, the plexiglass top cover, and the like. We've done this a few times, and have the process down to a few $1000, usually for three tester units. Of course the cost of developing the tester firmware and host software is the biggest expense.
In general, figure the tester is roughly of the same level of complexity as the thing it is testing. You need to alert management of this early so that they know it's coming. All too often they think you're done with a project when you get the first prototype working on the bench.
Even if you've warned them all along, you still often find inexperienced managers that don't want to take 2 months to develop a proper tester, after having just spent 4 months developing a product that needs testing. The best solution I've found is to just include a tester in the schedule and budget from the first day, although even that doesn't always work. Particularly inexperienced low level managers have a great capacity for being penny-wise and pound-foolish.
Short answer: Yes - a bed of nails is a good way to accomplish test of your product.
Disclaimer: I work as a test design engineer creating testers for this purpose.
Here is what I can add:
Create a detailed test specification. Whether you or someone else creates a system to test your product, you’ll need clear documentation on what and how accurately you to test it. It also helps to clarify for yourself what elements of the product you want tested. A test spec will also detail what test points on your PCB you want to connect to with a test system.
The type of test you describe is typically referred to as Functional Test (FCT). From my experience there are three main aspects of a FCT system:
Fixture; typically bed of nails, but other fixtures can utilize cables/connectors.
Test Equipment; programmers, software controlled instrumentation (often from National Instruments and/or Keysight) and a PC running software that executes and logs the results of the test.
Software; drivers to communicate with instrumentation & programmers and typically a user interface for the person running the test system.
Depending on your resources, you can purchase a bed of nails fixture, wire it to instrumentation, and write firmware/software to test the product. Many companies that sell test fixtures also provide turnkey solutions where they will work with you to select instrumentation and develop software for the test system.
I design custom PCBs for test systems when necessary, but there is lots of good COTS (commercial, off the shelf) instrumentation for doing exactly what you describe.
For more pictures of what fixtures and test systems look like - the company I work for has a couple pdfs listed under their tutorials section: Circuit Check Tutorials
In addition to the excellent answer from Olin, you should capture all your automated test results, which implies you have a very capable tester; what follows is useful to explain to management just why you need a very capable test setup.
On that note, manual test time is very expensive compared to automated test time, so a capable automated test set-up will inherently save money.
Automated test time still costs money, so after you have a reasonable data set (1,000 is a good start), consolidate the results and see what tests have not failed on any unit.
These tests should be performed on a batch basis where the first item and some other percentage are subject to these tests. (There are AQL tables available to figure out how many units should get these tests).
Note that the batch based testing is to ensure that a batch of built units or components do not exhibit unexpected faults; if the line gets excessive failures it can be stopped before accumulating too many failed units so whatever the issue happens to be can be fixed.
As you get more and more test results you can refine the testing done, which can significantly reduce the cost and time involved in production testing.
This is, of course, Statistical Process Control and the proper application of it can generate significant savings which go straight to your bottom line.
The last time I did this, I managed to shave $6 per unit off the test (on average), and running 20k units a month - well, it becomes clear when you look at the numbers.