Traceability: requirement to test to result

When you order a parcel you get a tracking number.

That number joins four things: the order you placed, the item that was picked, the van it went on, and the moment it arrived. Nobody finds this thrilling. Everybody wants it the day the parcel does not turn up.

A requirements traceability matrix is that tracking number for testing. It joins the requirement to the cases that cover it, and the cases to their last result.

One question, answered without a week of archaeology: which tests cover this, and did they pass?

What it actually is

Three columns and a date. Everything else is decoration.

• The requirement. A story, an acceptance criterion, a clause in a spec, a regulation.
• The tests. Which cases or automated checks cover it. Named, not counted.
• The result. Pass or fail, on which build, when.

Read left to right and you get coverage. Read right to left and you get impact, which is the direction people forget. When a test fails, which requirement is now unproven? When a requirement changes, which tests must be rewritten?

Why you should care about this

Because the question always arrives later, and always under pressure.

A customer says a feature never worked. An auditor asks what you tested before the March release. An incident review asks whether anybody had checked the thing that just broke. Without traceability, answering means reading old tickets and trusting memory. With it, the answer takes a minute.

The AI layers have made this sharper. Governance frameworks now ask for exactly this evidence, and much of what they want is testing evidence with dates and versions attached. That is the same material described in AI governance, and traceability is the shape it wants to be in.

How to do it without a project

1. Trace at the level people ask about. Usually the acceptance criterion or the story. Tracing every sentence of a spec is a project nobody finishes.
2. Link, do not copy. A case that names its story, and a run that names its build, is traceability. Retyping requirement text into a spreadsheet is data entry that goes stale within a sprint.
3. Let the tracker do it. Cases linked to stories, runs linked to builds, defects linked to cases. This is exactly what test management tools are for, and it means the matrix is a report rather than a document.
4. Use a spreadsheet when the tracker cannot. For a contract, a regulation or a security requirement that has no ticket, a five-column sheet is honest and fine.
5. Include the automated checks by name. A test file path is a perfectly good entry, and it pairs with scoring what to automate first. Coverage that ignores automation is misleading.
6. Record gaps as rows, not blanks. An empty cell reads as an oversight. "No test, accepted by product on 12 August" reads as a decision.
7. Refresh it at release time. The matrix is only evidence if the results in it belong to the build you shipped.

A filled-in matrix

Here is the gift-card release at Willow Books, traced at acceptance-criterion level. Nine rows, and it took twenty minutes because the links already existed.

The two interesting rows are the last ones. One is a failure that was accepted in writing, by a named person, on a date. The other is a requirement with no test and a reason. Both are far more useful than a green cell, because they record a decision instead of hiding a gap.

How to show you know it

• A one-page matrix for a real release, refreshed at release time. Attach it to the summary report so both live together. Most teams have never produced one.
• A gap row with a name and a date. It proves you record decisions rather than only outcomes.
• The reverse lookup. "This test failed, so these two criteria are now unproven." Reading the matrix backwards is the part people miss.
• Traceability that is a report, not a document. If you can produce it from the tracker in a minute, you have built the durable version.