The test plan was written two years ago by the reliability engineer who ran the qualification. He left the company eight months later. Since then the product moved to a new PCB supplier, the operating temperature range was extended by 10°C at the cold end, and the customer changed the deployment environment from controlled indoor to uncontrolled industrial. Nobody updated the test plan. The document still described the old supplier, the old range, and the old environment.
When the customer asked to review the test plan before accepting the qualification results, it took four days to reconstruct what had actually been tested — and another three weeks to explain why the deviations from the plan did not invalidate the results. The qualification was accepted. But the process cost more time and credibility than the original test plan would have taken to maintain correctly.
This is what a test plan that survives that conversation needs to contain.
What a test plan is — and what it is not
A test plan is not a record of what was done. That is the test report. A test plan is a commitment made before testing begins: this is what we will test, under these conditions, to these criteria, using this equipment, with these samples. It exists so that anyone — a customer, an auditor, a new engineer — can look at the plan and the report together and verify that what was done matches what was committed to.
A test plan that is written after testing is a test report with a date changed. It has no value as evidence of pre-planned intent. If your qualification documentation was assembled retrospectively, that is the first thing an experienced auditor will identify — and the first thing a customer quality engineer will question.
The six sections every environmental test plan must contain
Section 1: Scope and purpose. What is being tested, why, and for what application. One paragraph. The product name and revision, the intended deployment environment (not just the operating range — the actual physical context: ambient temperature, humidity, vibration profile, altitude), and the purpose of the test (qualification, verification, development, HALT). If the product has multiple variants with different hardware, each variant is either in scope or explicitly excluded.
Section 2: Applicable standards and deviations. List every standard referenced in the test conditions — IEC 60068-2-14, JEDEC JESD22-A104, ISO 16750-4, MIL-STD-810, ICH Q1A, whatever applies. For each standard, note the edition year. Then list every deviation from standard conditions — if the standard specifies 10°C/min and the chamber achieves 5°C/min under load, that is a deviation. It goes in the plan before testing begins, with a technical justification for why the deviation does not affect the validity of the results. A deviation documented in advance is a planned deviation. A deviation discovered after testing is a non-conformance. They are treated very differently by customers and auditors.
Section 3: Test conditions. Every test is specified to the level of detail required to reproduce it. For temperature cycling: T-low, T-high, ramp rate (air or DUT — specify which), dwell time (at air setpoint or DUT equilibrium — specify which), number of cycles, and whether the DUT is powered during test. For humidity: temperature, humidity setpoint, transition conditions, duration. For HALT: thermal step stress profile (step size, dwell duration), vibration step stress profile (Grms level, dwell duration), combined stress sequence. For stability: storage conditions (temperature ± tolerance, humidity ± tolerance), sampling intervals, number of time points, test methods at each time point. Vague specifications like "temperature cycle per IEC 60068-2-14" are incomplete — they define the method but not the conditions. Conditions go in the test plan.
Section 4: Test equipment and calibration. Chamber manufacturer, model, and serial number. Controller type. Calibration certificate reference number and expiry date for each piece of measurement equipment used. If the test requires monitoring the DUT during cycling — powered tests, thermocouple measurements, functional checks at temperature — specify the monitoring equipment and its calibration status. A test plan that specifies conditions without specifying the equipment that will verify those conditions are met is a plan with a gap auditors reliably find. The calibration requirements for chamber equipment are covered in Environmental Test Chamber Calibration.
Section 5: Sample definition. How many samples, which revision of hardware and firmware, traceability information (serial numbers or batch/lot references), and whether samples will be used for destructive or non-destructive analysis after testing. If samples are repaired or reworked before testing, document it here. If samples are pre-screened by functional test before environmental exposure, specify the screening criteria. The sample size rationale — why three samples rather than two or five — goes here. See How Many Samples Do You Actually Need for Environmental Testing for the statistical framework.
Section 6: Acceptance criteria. What constitutes a pass. This is the section most test plans treat as optional, and it is the section that causes the most problems. "No failures" is not an acceptance criterion — it is ambiguous. No failures measured how? By what test method? Against what specification limit? At what point during or after environmental exposure? Acceptance criteria must be defined before testing begins and must be specific enough that two different engineers reading the plan would make the same pass/fail determination for the same result. For electrical parameters: specify the measurement method, the measurement conditions (temperature, time after removal from chamber), and the tolerance relative to pre-test values. For mechanical: specify the inspection method and the defect classification. For functional: specify the test sequence and the pass criteria for each functional parameter.
The section most test plans are missing
Revision history. A test plan that has no revision history is a test plan that has never been updated — or one where updates were made without being recorded. Either way, it is a document that cannot be trusted as a current representation of the test. Add a revision history table: revision number, date, author, and a one-line description of what changed. Update it every time the plan changes. When the PCB supplier changes, update the plan. When the operating temperature range extends, update the plan. When the deployment environment changes, update the plan. The revision history is the chain of custody that allows a customer three years later to verify that the test plan in front of them reflects the product and environment that was actually tested.
What auditors actually check first
Not the test conditions. The date of the test plan relative to the date of testing. If the test plan was created or last modified after testing began, the first question is why. The second thing auditors check is the acceptance criteria section — specifically, whether the criteria were defined before testing or appear to have been written to match the results. Pre-defined acceptance criteria that are just barely passed by the actual results are a yellow flag. Pre-defined criteria that are conspicuously easy to pass are a red flag. The third check is calibration records — whether the equipment used was within its calibration interval at the time of testing. These three checks take less than ten minutes and reveal more about the quality of a test programme than reading the entire report.
The full documentation requirements — what test records must contain and how long they must be retained — are covered in What Environmental Test Records Must Contain. The deviation handling process — what to do when the test does not go according to plan — is at How to Handle Test Deviations and Chamber Excursions.
The mistake that costs more than a missing section: copy-paste from the last programme
The fastest way to write a test plan is to open the one from the last product and change the part number. It is also the most common source of test plans that fail audit. The previous programme's plan was scoped for a different deployment environment, written against an earlier revision of the relevant standard, and built around acceptance criteria tuned to a different product's failure modes. Copying it forward carries all of that mismatch silently into the new plan — nothing throws an error, nothing flags the inherited assumptions, and the document reads as complete because it follows the right template.
The check that catches this before it costs a programme: read Section 1 (scope) and Section 6 (acceptance criteria) as if you had never seen the previous product. If anything in those two sections only makes sense because you know what the last plan said, the document has not actually been rewritten — it has been relabelled.
What Section 6 looks like when it is done right
Most engineers know acceptance criteria need to be specific. Few have seen what specific actually looks like in practice, because most test plans they have read got away with vague language. Compare these two versions of the same requirement.
Vague: "Unit shall show no functional failures after thermal cycling."
Specific: "Following 500 cycles per the profile in Section 3, each unit shall be removed from the chamber, allowed to reach 23°C ± 2°C ambient for 30 minutes, then powered on. Output voltage at TP4 shall measure 5.0V ± 0.25V under a 2A load, measured with a calibrated DMM within 1% accuracy. Any unit outside this range constitutes a failure of this criterion."
The second version leaves no room for two engineers to disagree about whether a borderline result passed. That is the actual test of whether an acceptance criterion is finished: hand it to a colleague who was not in the room when it was written, give them the raw measurement, and see if they reach the same pass/fail call you would.
When the test plan and the standard disagree on a number
Standards leave gaps on purpose, in places where they expect product-specific tailoring. MIL-STD-810 is explicit about this for its test conditions; the IEC 60068 series specifies methods but routes the actual severity levels to the referencing product standard. A test plan that simply states "per IEC 60068-2-14" without specifying T-low, T-high, and cycle count has not closed that gap — it has passed it on to whoever runs the test, who will fill it in with their own assumption, possibly a different one than the engineer who reads the report six months later. Closing every gap a standard leaves open is not extra work; it is the work the test plan exists to do.