Datum
All skills
TestingRev. Q3 2026

Test plan builder

Convert requirements into a verification test plan: a requirement-to-verification matrix, pass/fail criteria with measurement uncertainty considered, sample sizes with statistical basis, test sequencing, and fixture needs. Use whenever the user needs a DVP&R, qualification plan, test protocol, or verification matrix, asks how many samples to test, how to prove a requirement, or what tests a new design needs before release.

Julien Dubois portraitJulien DuboisTest EngineerInstron logoInstron

Likes are peer vetting. Like this skill if it held up in your work.

Test Plan Builder

Turns a requirements list into a plan a test lab can quote and a reviewer can approve: every requirement gets a verification method, every test gets a number to beat, and sample sizes have a stated basis instead of folklore.

Required inputs

  1. The requirements, ideally numbered with values and conditions. If the user has only a feature description, draft candidate requirements first and get confirmation; untestable requirements are the root problem in most weak test plans.
  2. The product's life and environment: duty cycle, temperature range, vibration/shock exposure, environmental sealing needs, standards invoked (IEC, MIL-STD-810, ISO, ASTM, customer specs).
  3. Program constraints: number of prototypes available, schedule, lab capabilities in-house vs. external.
  4. Risk context: which failures are safety-relevant, which are warranty/annoyance. This drives confidence levels and sample sizes.

Method

  1. Verification matrix first. For each requirement assign the method: Test, Analysis, Inspection, or Demonstration. Push requirements to analysis or inspection where a test adds no information (dimensional compliance is inspection; a load case bounded by an existing qualified case is analysis). Testing everything is a budget statement, not rigor.
  2. Pass/fail criteria. Each test gets a quantitative criterion traced to the requirement, with the measurement method named. Check the uncertainty ratio: the measurement uncertainty should be small relative to the tolerance being judged (aim for 4:1 or better); flag criteria where the lab's instrument can't discriminate a pass from a fail.
  3. Sample size with a basis. Offer the standard options and pick one per test:
    • Attribute demonstration: success-run formula, n = ln(1 minus confidence)/ln(reliability); e.g., 22 units zero failures demonstrates 90 percent reliability at 90 percent confidence; 45 units for 95/90. State the R/C being claimed.
    • Variables data: smaller samples (n = 5 to 10) with a tolerance-interval or Cpk-style margin argument; prefer this when the response is measurable, since it buys confidence per unit.
    • Durability: test to a life multiple (commonly 2x design life with defined degradation limits) or test-to-failure on fewer units to learn margin. State which philosophy and why. Never present a sample size without its confidence statement.
  4. Test levels and margins. Qualification levels above expected environment by the standard's margin (e.g., accelerated factors for thermal cycling, vibration test levels enveloping the measured or specified environment). Show the acceleration model used (Coffin-Manson, Arrhenius) and its assumed parameters when compressing life.
  5. Sequencing. Order tests on shared units to maximize information: nondestructive and baseline characterization first, environmental exposures in the sequence the standard requires, destructive tests last. Flag where sequencing on shared units confounds results and a dedicated unit is worth it.
  6. Logistics. For each test: fixture and instrumentation needs, data to record, and the failure criteria including "what counts as an anomaly worth stopping for." Include a units-and-serial tracking table so results trace to hardware configuration.

Output format

  • Verification matrix: requirement ID, method, test ID, criterion, sample size with R/C basis
  • Per-test one-block protocol summaries: purpose, setup, levels, duration, pass/fail, samples
  • Test flow diagram described in sequence order with shared-unit assignments
  • Gap list: requirements that are currently untestable as written, each with a proposed rewrite

Guardrails

  • Refuse to bless "test one unit and call it qualified" for a reliability claim; one unit demonstrates feasibility, and the plan should say exactly that.
  • When a standard is invoked, follow its levels and durations and cite the section; do not average between standards.
  • Distinguish verification (did we build it to requirement) from validation (does it work for the user); if the requirements themselves are unproven, say a validation activity is missing rather than burying it.
  • Flag schedule fantasy: sum the test durations, include failures and retest loops at a stated assumption, and give the honest calendar estimate.