What Belongs in a Test Configuration Record — and Why You'll Need One in Six Months
Six months after a test campaign closes, someone will come back to your data with a question.
Which firmware build was on the controller when we ran the sweep? What part number was the pressure sensor? Was the anti-skid channel disabled that day, or is that a different data set?
If you can't answer, the data is in limbo. It exists, but you can't defend it. And the answer isn't "check the test report" — the report tells you what happened, not what was there when it happened.
That's what the Test Configuration Record (TCR) is for. It's a short, boring document that captures the frozen configuration of the test article and setup at the moment of test execution. When someone comes back six months later, the TCR is the artifact you point to.
This post is about what goes in one and where teams get it wrong.
What a TCR Captures
A TCR is not a test plan and not a test report. It sits between the two. It answers the question: what was actually there?
Specifically, it freezes and documents:
- Test article identification — every major component's part number, serial number, and revision level.
- Modifications and engineering orders that have been incorporated into the article.
- Approved deviations and waivers active at the time of test.
- Known limitations or open restrictions.
- Software and firmware versions on every controller and DAQ.
- Physical setup and support equipment — hydraulic carts, load fixtures, cooling, power supplies.
- Utilities and their specifications (source, range, tolerance).
- Every instrumentation channel — sensor P/N, S/N, range, calibration due date.
- DAQ configuration — sample rate, anti-alias filter, storage format.
- Verification signatures for each configuration area.
- As-configured photographs of the setup.
The photographs matter. A P/N table can drift from reality. A photo of the test cell with the article in place, taken the day of freeze, cannot.
Why It Exists
Three problems the TCR solves.
Data defensibility. Requirement closure needs a traceable article. If a reviewer asks "what did you test?" and the answer is "the article listed in the test plan," that's not evidence. The TCR is what turns an article name into a traceable configuration with signatures.
Retest ambiguity. If a requirement fails and needs retest, the first question is whether the failure was the article or the configuration. Without a frozen baseline, you can't tell. Sometimes the article had a disabled channel, or a bench hydraulic power unit stood in for aircraft hydraulics, and the failure was environmental. Without the TCR, you retest blind.
Six-month questions. Test programs churn. People rotate. If the engineer who ran the test isn't around when the data gets challenged, the TCR is what carries the memory. Without it, tribal knowledge walks out the door with the engineer.
The Structure I Use
The TCR template I built for the Test & Validation Essentials Bundle covers eight sections. Each is short — the whole document runs about ten pages including tables and photographs.
1. Introduction. Purpose, scope, reference documents, acronyms. Front matter that anchors the record.
2. Configuration Baseline. The test event, the governing test plan, the freeze date (usually tied to a TRR reference). This is the anchor point — everything downstream is frozen relative to this.
3. Test Article Configuration. The article identification table (P/N, S/N, rev), incorporated modifications and engineering orders, approved deviations and waivers, and any open restrictions or known limitations. This is the section reviewers spend the most time on.
4. Software & Firmware Configuration. Versions and builds on every controller, DAQ, and logic component. One row per item, verified box.
5. Test Setup & Support Equipment. Physical setup description with references to setup diagrams. GSE list with calibration status. Utilities and sources (hydraulic pressure, electrical bus voltage, etc.) with specifications.
6. Instrumentation & Data Acquisition. Channel list — parameter, channel ID, sensor P/N, S/N, range, units, calibration due date. DAQ configuration — sample rate, anti-alias filter, storage format, archive location. This is what makes the data reproducible.
7. Configuration Verification & Photographs. A verification table showing who confirmed each area (Test Article, Software, Setup, Instrumentation) and when. As-configured photographs of the test article and setup. A post-test change log for anything modified after test that could affect future work.
8. Approvals. Responsible Engineer, Engineering Manager, and Test Engineer Manager signatures.
Nothing in this structure is fancy. What matters is that every field gets filled the day the configuration is frozen — not later, not from memory.
Where TCRs Go Wrong
Two failure modes I keep seeing.
"We'll photograph it after the test." Then someone bumps a cable during teardown and the post-test photos show a different setup than what was tested. Photographs have to happen at freeze, not at teardown. If your only picture of the setup was taken while the article was being disassembled, you don't have a picture of the tested configuration.
"Calibration is fine, we don't need to record the due date." Every DAQ channel needs its calibration due date on the record. Six months later, if a sensor is found out-of-cal at its next check, you need to know whether it was in-cal on your test day. If the record doesn't have the cal-due date, you can't tell — and any data that channel produced becomes questionable.
Both failure modes are fixed by treating the TCR as a live document during test prep, updated as the article configures, rather than as a compilation task after the fact.
The TCR template I described above ships with the Test & Validation Essentials Bundle. It includes all eight sections with example entries from a brake system iron bird test, so you can see how each table fills out before starting on your own program.
Get the Test & Validation Essentials Bundle → https://solriseengineering.gumroad.com/l/tier1-testandvalidation