Test Plan → Test Card, or Test Plan → Test Procedure → Test Card?

I've seen two approaches to test documentation and I'm genuinely curious which one works better in practice.

Approach A: Test Plan → Test Card.

Plan defines objectives, conditions, pass/fail. Card goes straight to step-by-step execution. Two documents, fewer reviews, faster turnaround.

Approach B: Test Plan → Test Procedure → Test Card.

A procedure sits between — capturing methodology before the card handles execution. Three layers, clearer role separation, more to maintain.

Both exist. NASA and many flight test orgs use two layers. Larger OEMs and qualification programs often use three.

The trade-off comes down to change management. With two layers, the card absorbs configuration changes. With three, the procedure absorbs some before it reaches the card.

I've worked with both. Neither is wrong.

Why This Question Matters

This isn't an academic question. The documentation hierarchy directly affects how fast a test program can respond to change.

When an aircraft gets a new restriction, or a software update changes system behavior, or a squawk limits the test envelope — something in the documentation chain has to absorb that change. The question is: which document absorbs it, and what's the approval burden?

In a 2-layer system, the test card absorbs most changes. The test plan stays stable because it only defines high-level requirements and conditions. The card gets updated to reflect current configuration, restrictions, and procedures. This keeps the approval chain short — test cards often need test engineer approval only, not authority-level signatures.

In a 3-layer system, the test procedure acts as a buffer. Methodology changes go into the procedure. Execution-level changes go into the card. The test plan rarely needs revision. This adds a document to maintain, but it also means the test card stays focused purely on execution — step, action, record.

Organizational Factors

The choice often depends on how systems engineers and test engineers divide responsibilities within the organization. In some programs, the systems engineer owns the test plan and procedure, while the test engineer owns the test card. In others, the test engineer owns everything from plan to card.

Company size, regulatory environment, and program maturity also play a role. Startups and smaller flight test organizations tend toward 2-layer for speed. Established OEMs with formal quality systems tend toward 3-layer for traceability and audit compliance.

There's no universal right answer — but understanding why your organization chose its approach, and whether it still serves the program, is worth examining.

For structured test documentation templates, visit solriseengineering.com.

Get the Test & Validation Essentials Bundle → https://solriseengineering.gumroad.com/l/tier1-testvalidationessential