Hardware Test Plan – for complex or mission-critical products

What a hardware test plan does

A hardware test plan explains how a product is to be tested:

1. stimulus to be provided,
2. method of measurement, and
3. 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:

1. 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).
2. 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.

What a hardware test plan does NOT do

A hardware test plan does NOT provide the specific details needed for an operator to execute tests on the part.  That’s reserved for the test procedure.  A test plan doesn’t explain how to load a unit into the fixture, it doesn’t explain how to set up equipment, and it doesn’t walk through user prompts.

A fuzzy area in a test plan is the level of detail to include.  You want to include the class of equipment (e.g. DMM, spectrum analyzer, power meter) along with any critical parameters about the equipment, but you don’t necessarily need to call out to the level of model numbers.  An exception to this is if you’re dealing with super unique equipment or equipment you know has been vetted to produce the correct measurement.

A hardware test plan also does not define the automated test system (if one is going to be utilized).  It might allude to it, but the test system documentation comes into play after the test plan, and before the test procedure.

Hardware test plan makeup

Consider the following sections in your test plan:

1. DUT Overview – this explains what the product does at a high level, how it’s used in operation, and its key functions.
2. Test equipment system diagram – this provides a basic block diagram overview of the main hardware components of the test equipment or automated test system.
3. Test overview – a description of each test. How the test is performed, the stimulus involved, how results are calculated, test limits, test time goals, the intent of the test, the equipment involved, etc.  See the section below for more detail.
4. Test fixture needs – describe how the fixture interfaces to the DUT and how the operator interacts with it (physically, so how they connect cables and whatnot, not things like software user prompts).
5. Equipment List – this is a list of all the equipment needed to perform the tests during manufacturing.
6. Capacity analysis – analyzes and provides estimates for the amount of product that can leave the factory over a period of time (takt time) from a test standpoint.

Test Overview details – the following should be described for each test:

1. Test intent – Explain why the test is being conducted. It should describe at a high level what aspects will be tested. For a manufacturing test the testing of the unit should be scoped to making sure it was built correctly and adheres to critical design specifications. It should not be a design validation test.
2. Test limits – List the limits for pass/fail
3. Test time & takt time goals – these are estimates at this point, based on a combination of historical data and bottom-up analysis.
4. Test equipment needs – type of equipment and any unique capabilities

The key is to provide just enough detail to be useful, but not so much that the stakeholder’s eyes glaze over when they get five minutes into reading the doc.

Next Steps

If you’d like help with automating your test setup (the entire system or just the software), reach out for a custom automated test system consultation.

If you’re in learning mode, here’s some info that you might find useful:

• If you’ve just got a quick question, ask a LabVIEW Expert.
• If you’re interested in various ways to test hardware products, you’ll want to see our hardware product testing methods guide.
• Commissioning Custom Test Equipment – Steps to take and Gotchas to avoid
• Hardware Product Testing Strategy – for complex or mission-critical parts & systems
• Automated Hardware Testing – What Automated Hardware Testing is. Why do it. Types of Automated Hardware Testing. Commonly tested products. How to do it