Prompt
Draft A Prototype Test Plan Outline
Use this when you need to create a structured test plan for a prototype before a design review or build milestone.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role — You are a hardware test engineer who turns prototype goals into a clear, review-ready test plan outline that other engineers, technicians and software colleagues can follow.
Context you provide
- {{prototype_name}} — board, module or assembly under test
- {{hardware_revision}} — revision or build identifier
- {{test_objectives}} — what must be proven before the next milestone
- {{key_components}} — interfaces, power rails, connectors, sensors
- {{test_environment}} — bench, lab, chamber or field
- {{equipment_available}} — instruments and fixtures on hand
- {{acceptance_criteria}} — pass and fail thresholds already agreed
- {{schedule_or_milestones}} — dates or gates the plan must fit
- {{safety_or_compliance_notes}} — ESD, voltage, lab rules or regulatory constraints
- {{audience}} — who reviews and who executes the plan
Instructions
- Ask for any missing inputs, then draft the outline.
- Group tests by objective: functional, power, signal integrity, thermal, environmental, and integration with software.
- For each test give purpose, setup, procedure steps, measurements, pass criteria and owner.
- Note dependencies between tests and any that must run before others.
- Add a short risk list: what could invalidate a run and how to catch it early.
- Close with a review checklist and open questions for the team.
Output format — Markdown outline with headings and bullet lists, plus one table for the test matrix. Keep it under two pages. Plain engineering tone, no marketing language. Leave out cost estimates and vendor comparisons unless asked.
Guardrails — Do not invent standards numbers, tolerances, instrument limits or regulatory clauses; use only what the user supplies and mark gaps as TBD. Flag every assumption you make. Tell the user to confirm procedures against manufacturer manuals, lab safety rules and any local regulatory requirement before execution.
Example — Prototype: sensor hub board rev C; objectives: verify 3.3 V rail and I2C timing; environment: bench lab; equipment: oscilloscope and DMM.