What Is a Test Plan and Why Should You Approve It Before Testing Starts?

← All guides

A quotation tells you what you will pay. A test report tells you what was measured. Between those two documents sits a third one that most clients never open: the test plan. It is the laboratory's written statement of what exactly will be measured, on which configuration, against which editions of which standards. Approving it takes twenty minutes. Not approving it is where most mid-project arguments, schedule slips and surprise retest fees begin.

What a test plan actually contains

A plan is short - typically two to five pages - but every line in it later shows up in your report. It normally states:

• Product identity. Model number, hardware revision, and the firmware version that will be on the sample.
• Tested configuration. Which adapter, which cables, which antennas, which accessories, and how many samples.
• Operating modes and functions. Every radio mode (Wi-Fi, Bluetooth, proprietary 2.4 GHz, sub-GHz), every power state, and which of them is claimed to be the worst case.
• Standards and editions. The emission and immunity standards, the safety standard, and the radio standards - each with its edition year, because the edition is what your buyers and market surveillance will check.
• Deliverables. Report format, whether raw data and setup photographs are included, and which documents (draft declarations, CB paperwork) the project is expected to feed.

The three documents are easy to confuse, so it is worth putting them side by side:

	Quotation	Test plan	Test report
Written by	The sales or project team	The test engineers	The test engineers
States	Price, scope in commercial terms, timeline	Configuration, modes, standards, editions, methods	What was actually measured and the results
Signed or approved by	You (commercial acceptance)	You (technical acceptance) - the step most often skipped	Nobody approves it; it records what happened
When it helps you	Before the PO	Before the booking, while changes are free	After the fact - too late to change what was covered

The asymmetry is the whole point. The report is fixed once the bench work is done. The plan is still fully negotiable the day before testing starts. That is the last moment where fixing a scope problem costs nothing.

Why the modes and configuration lines matter most

In practice, the plan's mode and configuration sections are where projects are saved or lost. Three situations we run into repeatedly:

The mode that never made it onto any list

A device with Wi-Fi and BLE arrives with paperwork that only ever mentions Wi-Fi - because the buyer asked about Wi-Fi, the previous quote mentioned Wi-Fi, and everyone in the chain copied that word. Nobody was lying; the BLE mode simply was never assessed. If that surfaces mid-project, the question becomes commercial: who pays for the added work, and does the delivery date still hold? If it surfaces in the plan review, it costs one email. This is the same failure we described when discussing why testing costs increase after a project starts - undeclared scope is the number one driver, and the plan is the instrument that surfaces it while it is still free to fix.

The adapter in the plan versus the adapter in the box

The plan names a 12 V/1 A adapter from a specific supplier type. Production later ships a 12 V/2 A unit from a second source. The emission and immunity results were measured through the original's output characteristics, so the report describes a configuration you no longer sell. When the plan is approved with the real adapter on it, that reference is frozen and any later change becomes a documented decision with a known consequence - the assessment we describe in component changes after certification. When the plan was never confirmed, the change is just a silent mismatch nobody can date.

The firmware version that kept moving

Firmware 1.2.0 goes into the plan. Two weeks into the project, engineering wants to ship 1.3.0 with a faster radio burst rate. With an approved plan, that question is well-posed: does the change alter the parameters the measurements depend on - output power, duty cycle, clock frequencies? If yes, those items need attention before the report is issued; if no, a documented note settles it. Without a frozen version in the plan, the argument has no anchor, and the report ends up naming a firmware that does not match any unit you ever shipped.

Worst-case selection - the part worth actually questioning

Emission standards such as CISPR 32 (and its FCC counterpart testing under ANSI C63.4 or C63.10) do not require every mode to be measured. They require the configuration and operating mode reasonably expected to produce the highest emissions, and that result is then taken to represent the product. Immunity standards under the IEC 61000-4 series work the same way per port.

That is efficient - but it transfers responsibility. If the mode you actually sell hardest was never declared, the "worst case" that was tested may not be your worst case. The report is internally consistent and the laboratory did nothing wrong; the product simply was not fully described. Reading the plan's mode list and asking "is the highest-power, highest-data-rate, all-transmitters-on state actually in here?" is the single most valuable question a client can ask before testing starts.

What goes wrong when the plan is never approved

Skipping the plan review does not usually cause a FAIL. It causes the four quieter outcomes that cost more:

• The mid-project scope dispute. Extra modes or configurations surface after the booking; the schedule either slips while they are negotiated, or they are left out and the coverage gap moves downstream to your buyer.
• The wrong edition on the standards list. Your buyer's requirement letter names specific editions. If nobody checked the plan against that letter, you can end up with a technically valid report that does not satisfy the contract - the mismatch between what was quoted and what was needed, which we cover in how the standard is chosen.
• The late surprise. A problem discovered in week three leaves no room to fix and re-verify inside the booked window. The same problem found at plan stage is a design note, not a delivery crisis.
• The report that does not match the shipment. Configuration drift between plan, sample and production - the gap that market surveillance requests and buyer audits love to find.

There is also a case where the right answer is to not book the slot at all: if you cannot yet name the final adapter, antenna, or firmware, a plan cannot describe the product you will actually ship. Testing a configuration you already know will change is paying bench fees for evidence that will need qualifying anyway. In that situation we would rather issue the plan with the open items marked and wait - pre-compliance work on the unstable parts is described in pre-compliance testing.

How to review a test plan in twenty minutes

1. Match the sample, not the brochure. Model, hardware revision and firmware version on the plan must equal what is in the shipping box to the lab.
2. Count the radio modes. One line per mode your product can transmit in. If a mode is missing, add it now.
3. Check the adapter, cables and antennas against what production actually packs - model numbers, not "compatible adapter".
4. Compare the standards list against whatever your buyer, platform or importer asked for in writing, edition numbers included.
5. Confirm the deliverables. Raw data, setup photographs, and any documents the project must produce for a certificate or scheme later - you cannot add measurements to a finished report, but you can make sure the plan asked for everything up front.
6. Sign or reply in writing. "Approved as written" or a list of corrections. Silence is what makes every later change an argument instead of a decision.

Where we fit

SZC-LAB issues a written test plan for every project before the booking is confirmed, precisely because we would rather settle these questions over email than over a retest invoice. Our plans name every radio mode, the exact adapter and cable models, the firmware version and the standard editions, and we ask the client to approve them or mark corrections in writing. Open items are allowed - declared and dated, rather than quietly assumed. During the project, if engineering changes anything that touches the plan, the first question we ask is whether the measured parameters are affected, and the answer goes on record either way. Our reports carry the tested configuration, setup photographs and the firmware version, so the document chain from plan to report to shipped product stays continuous. If your current project has a plan you are not sure how to read, send it over and we will walk through it line by line. The overall programme is described on our testing and certification page.

The paragraph worth remembering

A test plan is not a quotation and not a report. It is the laboratory's written definition of the measurement: which product revision, which firmware, which adapter and cables, which operating modes, which standards and editions. Everything the report can honestly claim is bounded by what the plan defined, and the plan is the last document in the chain that can still be changed for free. Approving it in writing before testing starts - especially the mode list and the adapter line - is the cheapest quality control available in the entire certification process.