DVT test report template: the sections and fields auditors check

A defensible DVT test report has eight parts: scope, unit identification, test configuration, an equipment list with serial numbers, the procedure revision, results against limits, deviations, and sign-off. Each field answers a question a reviewer would otherwise ask the engineer who ran the test. Copy the outline below, then fill it from run records instead of retyping.

DVT is the build where a production-intent design is checked against every requirement (EVT vs DVT vs PVT covers what runs in it). The report outlives the build. A design review reads it, then a customer's quality engineer, a certification body or a regulator, and later an engineer chasing a field return. Each asks whether a result can be reconstructed from the report and the records it cites.

What should a DVT test report include?

Use this outline as your template's skeleton; the last column is what each section must prove on its own.

Rows 2 through 8 and 10 are the eight core sections. The rest make the document identifiable and complete.

What do auditors check in a test report?

DVT reports have no single governing standard, but three public sources describe what reviewers of test evidence look for, and they agree closely.

NASA's verification report. The NASA Systems Engineering Handbook, section 5.3, says a product verification report "includes the requirement that was to be verified and its bidirectional traceability, the verification method used, and reference to any special equipment, conditions, or procedures used," along with "the results of the verification, any anomalies, variations or out-of-compliance results noted and associated corrective actions taken." The report also pins the "version of the product verified" and the "version or standard for tools, data, and equipment used," and the criteria for completing verification include "closure of all discrepancy and nonconformance reports."

Accredited lab reports. ISO/IEC 17025:2017 clause 7.8 sets what an accredited lab's report contains. NIST's Office of Weights and Measures summarizes it in a public crosswalk: review and authorization before issue, a unique report ID with its end marked, the method, an unambiguous item identification and, when necessary, its condition, results with units, a statement that results relate only to the items tested, the people authorizing the report, and a documented decision rule when stating conformity. In-house DVT reports are rarely issued under 17025, but the list describes a complete test report well (ISO/IEC 17025 records for automated benches).

FDA design verification records. Until February 2, 2026, 21 CFR 820.30(f) required device makers to document verification results, "including identification of the design, method(s), the date, and the individual(s) performing the verification." The QMSR, effective that day, incorporates ISO 13485:2016 instead, but those four items remain a sensible floor (medical device design verification).

The checks reduce to four questions: what was tested, how, what happened, and who accepted it. The outline answers each with a field rather than a paragraph.

How do you identify units under test?

A serial number alone does not identify a DVT unit. Units with adjacent serials can differ in board revision, reworked change orders and firmware. Record, per unit: serial number, hardware revision, assembly and BOM revision, firmware version, change orders applied, and condition when testing started.

Read what you can from the unit itself. A step that queries the firmware version at the start of each run records what was loaded, not what the build sheet says. If a unit is reworked mid-DVT, report it as a new configuration and keep both sets of results; a result taken before the rework does not verify the design after it.

What test configuration belongs in the report?

Configuration is everything outside the unit that can change a reading: fixture and revision, harnesses, loads, the unit's settings and operating mode, supplies, and environmental conditions. For environmental runs, such as the functional checks around a DO-160 environmental test, report the conditions logged during the run, not only the setpoints.

A line often missing is the list of differences from the production product: a debug header fitted, a substitute heatsink, logging firmware, a bench supply in place of the battery. Each is a reason a result might not transfer to the shipped design, and one undeclared difference makes a reviewer question the rest. A setup diagram with an ID and revision is cheaper than a paragraph and harder to misread.

How should the equipment list identify instruments?

A model number is not identification. For every instrument whose reading supports a verdict, list the function, manufacturer, model, serial, firmware, asset tag, calibration due date, and the steps that used it. The last column matters when a meter is later found out of tolerance: the report shows which results depended on it.

NASA's handbook expects the verification lead to ensure that "instrumentation were calibrated correctly." For a given run, that means joining the instrument's serial against calibration records for the run date, which works only if the serial was captured at run time. Instruments move between benches, so read identity from the instrument, not a station sheet. For SCPI instruments, *IDN? returns manufacturer, model, serial and firmware, and the session class in SCPI instrument automation with Python logs it per session. Calibration status in automated test records covers the calibration side.

Why does the procedure revision matter?

The limits live in the procedure. A report that says "per TP-0412" without a revision cannot show which limits applied, and procedures change during DVT: a limit tightens, a step is added, a dwell time is corrected. Record the procedure ID, revision, commit hash if it is in version control, who approved that revision and when, and the test software version.

Two checks follow. Approval should precede the first run it covers, or nobody reviewed the limits before they judged a unit. And if the procedure was revised mid-build, the results must show which revision produced each row. Hardware test traceability walks through pinning every link to a revision.

How do you report results against limits?

Report the number, not only the verdict. Each row needs the requirement, unit serial, measured value and unit, both limits, the comparison, the verdict and the run ID. An illustrative results section:

Four rules keep this section defensible:

• Compare before rounding. Judge the value as measured, then display it at a stated resolution; rounding first can flip a verdict.
• State the comparison. Inclusive or exclusive decides values that land on a limit.
• Show every unit and condition. Minimum, maximum and mean belong next to the rows, not in place of them.
• State the decision rule. If measurement uncertainty is significant against the tolerance, say whether verdicts use simple acceptance or a guard band.

How do you document deviations in a test report?

Four kinds of event belong here, each with its own record: planned deviations approved before the run (a substitute instrument), unplanned departures found afterward, failures outside limits, and anomalies within limits (a reset during a thermal soak).

For each, record an ID, what happened, affected units and steps, the cause if known, the impact on results, the disposition (accept, retest, repair, redesign), the approver, and any retest run IDs. Link the failure or nonconformance report rather than summarizing it.

Never let a retest replace a failure. The failed run stays in the record and the report, the retest is a new run with its own ID, and the deviation explains why the retest counts. Under NASA's completion criterion, an open discrepancy means verification is not finished, whatever the results table says.

Who signs off a DVT test report?

Three roles are typical: the author who compiled the report, an independent reviewer who checked it against the records, and an approver with authority to accept the results.

For electronic signatures on FDA-regulated records, 21 CFR 11.50 requires each signed record to show "the printed name of the signer," "the date and time when the signature was executed," and "the meaning (such as review, approval, responsibility, or authorship) associated with the signature." The same three items are good practice anywhere. A signature should name the report revision it applies to, and through it the runs the report covers.

After issue, changes go into a new revision that states what changed and why; NIST's 17025 crosswalk describes post-issue amendments as a further document that references the original. For electronic records, 21 CFR 11.10(e) puts it briefly: "Record changes shall not obscure previously recorded information."

How do reports drafted from run records reduce transcription?

Errors in DVT reports often enter through copying: numbers pasted from a log, serials typed from a label, limits taken from the test plan instead of the revision that ran, an equipment list carried over from the last report. Each copy can pick the wrong run or unit, and each ages separately from its source.

The fix is to split the report by source. Tables are generated from records; people write only the parts that need judgment.

A generator should refuse to print a row it cannot support. This sketch reads step records shaped like those in the traceability post, one per line, and fails on any record missing a field the table needs:

import json
from pathlib import Path
 
REQUIRED = (
    "run_id", "dut_serial", "step", "value", "unit", "limits.comparison",
    "verdict", "instrument.model", "instrument.serial", "timestamp",
)
 
 
def field(record: dict, dotted: str):
    """Look up a dotted path such as 'instrument.serial'; None if any part is missing."""
    for key in dotted.split("."):
        record = record.get(key) if isinstance(record, dict) else None
    return record
 
 
def load_steps(path: Path) -> list[dict]:
    """One step record per line; refuse any record a reviewer could not check."""
    steps = []
    for n, line in enumerate(path.read_text().splitlines(), start=1):
        if not line.strip():
            continue
        step = json.loads(line)
        missing = [k for k in REQUIRED if field(step, k) in (None, "")]
        if field(step, "limits.low") is None and field(step, "limits.high") is None:
            missing.append("limits.low or limits.high")
        if missing:
            raise ValueError(f"{path}:{n}: missing {', '.join(missing)}")
        steps.append(step)
    return steps
 
 
def results_table(steps: list[dict]) -> str:
    """Render the results section from stored values; nothing is retyped."""
    rows = [
        "| Run | Unit | Step | Measured | Low | High | Comparison | Verdict | Instrument |",
        "|---|---|---|---|---|---|---|---|---|",
    ]
    for s in steps:
        lim, inst = s["limits"], s["instrument"]
        rows.append(
            f"| {s['run_id']} | {s['dut_serial']} | {s['step']} | {s['value']} {s['unit']} "
            f"| {lim.get('low', '')} | {lim.get('high', '')} | {lim['comparison']} "
            f"| {s['verdict'].upper()} | {inst['model']} SN {inst['serial']} |"
        )
    return "\n".join(rows)
 
 
if __name__ == "__main__":
    print(results_table(load_steps(Path("runs/dvt-b2/steps.jsonl"))))

Because the tables are views of the record, they regenerate when a run is added, and every number traces to a run ID without anyone vouching for a copy.

How Galois drafts reports from run records

Galois is agent-driven test engineering for hardware teams: agents generate tests and instrument drivers, run them on real benches through the open-source galois-edge daemon, and turn the results into reports and a shared engineering record.

In the product today:

• A per-step record written at execution time. Each step stores the raw command and response, the measured value, the limits, pass or fail and the instrument ID. Each run stores the operator, the DUT serial and timestamps.
• Approval before a run. A draft sequence cannot run until it is approved, and an approved sequence that is edited must be approved again, so the procedure revision in a report was approved before it touched a unit.
• Three report paths. Évariste, the agent in the Galois platform, drafts a report from a run, a data-bound LaTeX template fills a house format from the record, or an engineer writes one in the built-in editor with a live preview (product).
• An audit log of every action, with actor, timestamp and resource (security).

Scope, deviation dispositions, conclusions and signatures stay with people. Évariste's draft is a draft: the run record is the evidence, and an engineer should review the report before anyone signs it. Teams that need records on their own infrastructure can run the platform as a dedicated single-tenant cloud or fully on-prem and air-gapped (deployment options). The next section produces the same results with Évariste instead of a generator script.

How to draft a DVT test report in Galois with Évariste

Évariste does the work of results_table.py, starting one step earlier, at the sequence that writes the records. Open it from the app sidebar (Ctrl+Shift+E) beside the DVT project; agent-driven test automation covers the wider loop.

Instruments. Ask "List connected instruments" to confirm the DMM, oscilloscope and thermocouple DAQ are connected. Ask Évariste to send *IDN? to each and copy the serial numbers into the report's equipment list; for an instrument outside the library, upload its manual and Évariste generates a profile that, after your review, it deploys to the edge and binds.

Objective. State the requirements and limits from the plan revision that will run:

Create two DVT sequences for the B2 build and name each step with its requirement ID and revision. At 25 °C: PWR-012 rev C, 3.3 V rail on the DMM, 3.200 to 3.400 V inclusive; PWR-014 rev A, 3.3 V ripple at full load on the oscilloscope, 50 mVpp maximum. At 45 °C ambient: THM-003 rev B, case temperature from the DAQ thermocouple, 70.0 °C maximum.

Draft. Évariste returns two draft sequences with one numeric_limit step per requirement, named "PWR-012 (C) 3.3 V rail, 25 °C" and so on. Each step calls a named command from its instrument's profile with a unit, a comparison and limits: both limits under GELE, inclusive, for the rail, and a high limit only for ripple and case temperature. The comparison load_steps() checks for is set before any unit is tested.

Review and approval. Before approving, check each limit against its requirement revision, the comparisons and the step names; reviewing a generated test plan has a checklist. Neither draft can run until you approve it. Every edit, in conversation or the sequence builder, is a new version with a diff that needs approval again. Lock the approved versions for production and cite them in the report's procedure section.

Run. Set the load, chamber and fixture yourself, then start each run with the unit's serial from Évariste or the app. galois-edge executes it on the bench while Monitor shows the channels live; commands you send from the conversation wait for your confirmation when flagged as dangerous. Each step writes the per-step record described above.

Results and interpretation. Ask which steps failed or passed close to a limit across the B2 runs. For the example above, Évariste would report THM-003 on SN-0144 at 71.8 °C against a 70.0 °C maximum, citing run 7f40. Record DEV-007's disposition in a project note, which Évariste cites alongside the run, and ask it to compare the retest with 7f40; both runs stay in the record.

Report. Ask it to "Generate a test report from the last run", or name a run such as 7f40. Its rows come from the run record, rendered to PDF or HTML through a LaTeX template in your house format, editable in the report editor and shareable to Slack. List each run ID in the DVT report's appendices.

You no longer write or maintain results_table.py, the required-field check, the runner that writes steps.jsonl, logging or a report script. What stays yours: requirement IDs and limits from the approved plan, review and approval, the load, chamber, fixture and safety, calibration due dates from your calibration records, and scope, dispositions, conclusions and signatures.

DVT report checklist before review

Run these checks before a reviewer does:

1. Trace one number to a run ID, unit serial, instrument serial and procedure revision using only the report and its cited records.
2. Every requirement in scope has a result, an exclusion or a waiver.
3. Every instrument's calibration due date falls after its last run.
4. Every procedure revision was approved before its first run.
5. Every failed run appears, with a closed deviation.
6. Limits in the results match the revision that ran, not the current plan.
7. Every signature shows a name, role, date and time, and meaning, and names the report revision.