A test result labeled only with an application version may be impossible to reproduce. The executable can stay unchanged while a limits file, instrument driver, calibration correction, or product recipe changes its behavior. Record the configuration that actually ran, not just the name shown in the application window.
NI’s TestStand deployment guidance emphasizes identifying components and dependencies when packaging a test system. Use the same discipline when defining the result manifest. Deployment identity and measurement evidence should refer to the same controlled set.
Define the manifest boundary
| Manifest item | Why it matters |
|---|---|
| Test sequence or executable | Identifies the implemented procedure |
| Product recipe and limit set | Identifies variant-specific behavior and acceptance |
| Driver and runtime dependencies | Supports recreation of instrument communication |
| Fixture and station configuration | Identifies the physical measurement route |
| Correction data | Explains adjustments applied to raw readings |
Choose stable identifiers that resolve to retained files. A label such as “latest” is not a version. Preserve the installed manifest with each run rather than querying a shared directory later, when its contents may already represent another release. A checksum can help detect a changed file, but it is useful only when the corresponding approved artifact and its purpose are also available.
Capture what was loaded
Have the station record the selected recipe and resolved file identities at execution start. Distinguish those values from what the user intended to select. If an application falls back to a default file when one is missing, make that event visible and prevent an unexplained result from being accepted as a normal run.
Include any operator-adjustable settings that affect the measurement. A controlled program can still produce different results when a range, settling interval, or channel map is changed outside the recorded recipe.
Verify a station update
- Save the previous manifest and approved package.
- Deploy the new package through a controlled process.
- Compare the installed manifest with the intended release.
- Run representative functional and boundary checks.
- Confirm that new results identify the updated configuration.
Use a defined rollback route if the update fails verification. Do not mix an old executable with a new limits file unless that combination has been explicitly reviewed and identified.
Close the change by retaining the release package, verification evidence, and the first affected result identity. This allows later analysis to distinguish a product shift from a test-system shift. The retest history guide explains how to preserve attempts made under different configurations without overwriting the earlier evidence.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist