Topics / Engineering practice
Test readiness review (TRR): checklist and exit criteria
A test readiness review (TRR) determines whether a planned test campaign is ready to run and produce usable evidence. Check the software version, procedures, expected results, environment and open problems before authorizing execution.
A practical TRR checklist
- Candidate: identify the build, configuration, dependencies and requirements being tested.
- Procedures: record inputs, setup, expected outputs and pass/fail criteria before execution.
- Environment: establish what the fixtures and instrumentation can actually stimulate and observe.
- Traceability: connect the planned cases to requirements and risk, including boundary and failure conditions.
- Operations: assign execution, observation and anomaly-handling responsibilities.
- Open problems: state which prevent the campaign from producing interpretable evidence.
Entry: the plan, procedures and candidate setup are available to inspect. Exit: record whether execution is authorized, its exact scope, conditions and unresolved actions. Readiness does not mean the software has passed the campaign.
NASA publishes software review criteria and adaptable checklists. The working checklist here is our own; use your project’s approved criteria for the actual decision.
What should the review leave behind?
Retain the reviewed baseline, a decision with its authority, the approved execution scope and each action’s owner and closure condition. Link the later verification report to that baseline so a different build or fixture cannot inherit the readiness decision silently.
Make the test repeatable before it begins.
A readiness review asks whether the planned execution can produce interpretable evidence. Identify the build, fixtures, instrumentation, configuration and responsible people. Resolve ambiguous pass criteria before seeing a result.
NASA’s software test-plan guidance describes progressive maturation of the plan through design reviews and completion by the exit of TRR. Your actual review scope follows the project’s applicable plan.
Source: NASA software handbook: software test plan. Scope and edition reviewed 3 October 2026.
Challenge an apparently ready setup.
Illustrative example
The fixture removes the invalid input.
A sensor-input campaign must show how the software responds to an out-of-range measurement. The fixture clamps every injected value to the valid range before the application receives it. Repeating the test cannot establish the rejection behavior, even though the test script contains the intended invalid value.
Inspect the value at the application boundary and verify that the observation can distinguish rejection from silent clamping. Repair the fixture or provide a separate controlled injection path before calling that case ready. Record any remaining condition the environment cannot produce.
- Can the environment deliver each consequential condition to the software under test?
- Does the observation distinguish the expected response from a fixture’s transformation?
- Are the candidate, fixture revision and injection configuration recorded?
- Who decides whether an instrumentation anomaly invalidates the result?
Distinguish preparation checks from the campaign.
Proof’s TRR assessment includes configured tests, coverage, formal-evidence and trace checks. Its name does not mean it replaces your readiness review or supplies a qualified environment.
proof gate trr --format markdownUse the output to inspect gaps and readiness observations. Keep the later execution report separate from the plan and any pre-campaign checks.
Try it on your software
Bring one verification campaign before it runs.
We can inspect whether its setup and observations can support the claims you need.