Test Coverage Link¶
Verification linkage tool — instantiates Traceability Linking
Links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible.
A pile of passing tests tells you the tests pass; it does not tell you whether the things you promised are the things you tested. Test Coverage Link closes that gap by drawing one specific, typed relation — verified-by — from each requirement, behavior, or risk to the test case and result that check it. Its whole identity is that single link semantic: not "relates to," but "is verified by, and here is the pass/fail outcome." Paired with a coverage rule — every safety requirement must carry at least one verifying link — the mechanism converts an unanswerable question ("is this behavior actually tested?") into a mechanical one: follow the link, or note its absence. What it surfaces is less the tests that exist than the requirements that have no test pointing at them.
Example¶
A team building infusion-pump firmware works under IEC 62304, which requires that each software requirement be verified. One requirement reads: "the pump shall stop delivery within 200 ms of detecting a downstream occlusion." Test Coverage Link ties that requirement to a specific bench test — occlusion injected, stop-time measured — and records the result and the firmware version it ran against. Multiply that across ~600 requirements and the interesting output is not the 580 that are green; it is the report the coverage rule generates: 17 requirements have no verifying link at all, and 3 are linked only to tests last run four firmware revisions ago. Two of the unlinked 17 turn out to be safety-classified. That list — not the passing suite — is what the team works down before the design review, because each entry is a promise no test currently keeps.
How it works¶
- Draw the verified-by link. Each requirement, behavior, or risk is connected specifically to the test(s) that check it, carrying the verification outcome (pass/fail) and the version tested, not merely a reference.
- Apply a coverage rule. A declared rule states what must be linked — e.g. every safety requirement needs at least one verifying link — so the mechanism can compute the gap set: required-but-unlinked items.
- Separate coverage from execution. A requirement can have a linked test that is stale or failing; the link exposes the difference between tested, passing, and unverified rather than collapsing them into one green bar.
Tuning parameters¶
- Coverage-rule scope — which items demand a verifying link (all requirements, only safety-classified ones, risks too). Widening the rule catches more gaps but raises the maintenance load.
- Link strength — whether a single linked test satisfies the rule or whether independent, redundant verification is required. Stronger rules suit high-consequence behavior and cost more tests.
- Freshness threshold — how recently the linked test must have run against the current version before the link counts as valid. Tighter freshness catches stale verification but flags more items after every change.
- Outcome granularity — whether the link records only pass/fail or the measured margin (stopped in 140 ms against a 200 ms limit). Margins reveal fragile passes but take more instrumentation.
When it helps, and when it misleads¶
Its strength is that it makes verification gaps visible, which no count of passing tests can do: the value is in the requirements with nothing pointing at them, exactly the ones most likely to ship unchecked.
Its classic distortion is mistaking a coverage number for verification. High structural code coverage — even a rigorous criterion like MC/DC, which requires each condition in a decision to independently affect the outcome — proves the code was exercised, not that it does what the requirement demanded[1]; a test can execute every branch and still assert nothing meaningful. The related misuse is running the link backwards: writing a thin test after the fact purely to turn a red coverage cell green before a review, so the link exists but verifies nothing. The discipline is to link to tests that assert the requirement's intent, keep the freshness threshold live so stale links don't masquerade as coverage, and treat the gap list — not the percentage — as the real output.
How it implements the components¶
Test Coverage Link fills the verification slice of the archetype's link machinery:
trace_link— draws the concrete requirement↔test relations the rest of the coverage picture is built from.link_semantics— its defining contribution: every link carries the specific verified-by meaning plus a pass/fail outcome, not a generic association.coverage_rule— declares what must be verified (e.g. every safety requirement needs a verifying link) and thereby defines the gap set the mechanism reports.
It does not anchor links to immutable revisions (version_anchor — Source Control Linkage), trace downstream blast radius (impact_link — Change Impact Report), or watch who owns and maintains the links over time (link_owner, exception_record — Traceability Dashboard).
Related¶
- Instantiates: Traceability Linking — provides the verification links that let the archetype answer "is this promise actually checked?"
- Consumes: Source Control Linkage can supply the version anchor that tells whether a linked test ran against the current revision.
- Sibling mechanisms: Traceability Dashboard · Source Control Linkage · Requirements Traceability Matrix · Change Impact Report · Citation Chain · Data Lineage Record · Decision Log · Audit Trail Record · Chain-of-Custody Record
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Test Coverage Link operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible.
Independent corroboration: The frozen evidence defines Test Coverage Link as 'Links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible', so its operative form is Representation, Specification & Plan.
Nearest alternative: Record, Log & Register — Test Coverage Link includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: The defining operation is: Links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible. In the engineering_design lineage, that operation is specifically evidenced by authoritative or primary work that requires bidirectional links from each requirement to verifying tests and uses the matrix to expose untested requirements. This makes engineering_design the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible.
- Security Studies & Intelligence Analysis — Security's adversarial analysis, integrity, and incident-response tradition provides a formative adjacent lineage for the same test coverage link operation.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus engineering_design), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: Links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible. In the engineering_design lineage, that operation is specifically evidenced by authoritative or primary work that requires bidirectional links from each requirement to verifying tests and uses the matrix to expose untested requirements. This makes engineering_design the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited NASA SWE-072 Requirements-to-Test Traceability directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=single_lineage records how the mechanism arose; domain_reach=multi_domain separately records how broadly it can now be applied.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] RTCA, Inc. Software Considerations in Airborne Systems and Equipment Certification. DO-178C. RTCA, Inc. (2011). Defines MC/DC through each condition's independent effect and distinguishes structural exercise from requirements-based verification. registry ↩