What a hardware test plan does
A hardware test plan explains how a product is to be tested:
- stimulus to be provided,
- method of measurement, and
- expected results,
as well as why each test is needed in the first place.
Ideally, a hardware test plan should usually be developed during the design phase of the product, but not completed until the product design is nailed down. Early involvement can allow test engineering to have input into DFM or DFT efforts. However, any custom test equipment needed should generally not be designed until the product has, or its subassemblies have, been implemented and finalized from a design standpoint, especially from a test equipment hardware standpoint, because test fixtures may need to be modified.
A common point of confusion occurs between test plans and test procedures. A test procedure is the document given to an operator on the production floor that details the step-by-step instructions for how to accomplish testing the product, or DUT (Device Under Test). A test plan on the other hand, focuses on the intent/why behind each test.
A hardware test plan considers not only the obvious information around test methods and test equipment, but also can include information on test time, takt time, and manufacturing capacity analysis.
Information from the hardware test plan is to be shared with two primary stakeholders, as well as some portion of management. The primary stakeholders are:
- Design engineering – they want to see that the most critical specs of the part are being tested appropriately. In short, they’re focused on test coverage. They also will be interested in the measurements to give them statistical feedback on design changes (e.g. a component changed, a supplier changed, a new board was spun).
- Manufacturing – they’re most interested in understanding how quickly they’ll be able to get parts out the door. This means they’ll care about takt time, testing time, yield, and how many test stations might be needed.
The goals from these two groups can often be competing, as there’s a natural tension between test coverage and production volume. A test engineer can sometimes feel a bit caught in the middle between these two groups. A balance needs to be maintained.