Establishing traceability between automated test cases and requirements has long been a challenge in the automotive industry. Without it, you can't prove requirements coverage—potentially missing tests and failing ASPICE or functional safety requirements. But if you try to build it, automated test cases are scripts while requirements are text—how do you map scripts to text? Both keep changing, so how do you keep traceability correct?

Must You Build Automated Test-to-Requirement Traceability?

This topic has been debated repeatedly within teams. Generally, test engineers tend to resist building traceability. From their perspective, automated test cases are written based on their understanding of requirements—they inherently feel the mapping exists, and spending time to formally link them is redundant. If software breaks later, just fix it then.

This attitude is clearly wrong. The earlier issues are found in development, the cheaper they are to fix. But if pursuing early coverage requires enormous effort, we have to question whether the workload should instead be deferred until problems appear.

Where does this enormous effort come from? Unlike manual test cases, automated test cases are written in script languages. Scripts don't map neatly to Excel rows for traceability—they're hard to link accurately to requirements. Automated test scripts update very fast, and requirements also change. When requirements change, the burden of updating traceability falls on test engineers—it's tedious, boring work.

But from a requirements engineer or project manager's perspective, not seeing coverage data between test cases and requirements is anxiety-inducing. This anxiety is even stronger when requirements come from a customer (甲方). Customers generally can't see how the supplier generates test cases or executes tests, so they need requirement coverage data as psychological reassurance (which is probably why ASPICE requires it).

So the question becomes: build traceability early to ensure no requirements are missed, or defer until bugs are found and then supplement test cases? We believe the former has value, but if it requires enormous labor, ROI is low—maybe the latter works better. Is it possible to achieve the former's goals without that much effort?

How to Build Automated Test-to-Requirement Traceability

I've summarized roughly these steps:

Step 1: Annotate corresponding requirement IDs (not names) in automated test case comments

This establishes traceability between test cases and requirements. Annotating requirement names is wrong—you can't later reliably identify which requirements are covered by matching names.

The prerequisite for annotating requirement IDs is that requirements have globally unique IDs. This sounds simple, but many teams can't do it. Some teams use Word for requirements—requirements have no IDs, only section numbers. Section numbers auto-change when sections are added or removed, and the mapping quickly becomes chaotic.

Some teams use Excel for requirements, and IDs follow team-defined rules. Beyond the fact that human-assigned IDs inevitably have duplicates and omissions, maintaining the ID rules requires team-wide discussion and correct execution, plus a dedicated configuration manager to audit regularly—not a cost-effective solution.

Annotating requirement IDs is correct, but the prerequisite is that requirements have correct, unique IDs.

Step 2: Obtain the requirements-to-test-cases traceability matrix

How? Manually extract requirement IDs and test case IDs into a matrix table. This works, but again—test cases need globally unique IDs. But test cases are maintained as scripts, which don't auto-generate IDs—back to the same dilemma: manually numbering test cases. Same drawbacks: error-prone, and a configuration manager must regularly pull test engineers for audits.

A better approach: automatically assign globally unique IDs to each test case, and auto-generate the traceability matrix.

Step 3: Maintain matrix correctness

How? If you manually create the matrix, you have to manually maintain it—that's huge workload.

New test case added: need a new test case ID (check the config table, find the right ID rule, see what number we're at), plus map to a requirement ID (find the corresponding requirement).

Test case deleted: need to remove the unused test case ID, and ideally that ID is never reused. Updates must propagate globally—if the file is offline (e.g., an Excel on everyone's computer), that's the start of a new disaster.

A better approach: ensure the matrix auto-updates. Whether test scripts add or delete cases, the table updates automatically. The matrix should be presented from a test plan perspective: how many requirements does this test plan cover, does each requirement have corresponding test cases, did each test case pass, were bugs found, were bugs resolved—presented in that order.