Requirements Traceability

Why it matters

Without links, coverage is a guess. A release report that says "212 tests passed" does not tell the product owner whether the refund rules were tested at all. With traceability the report can state, requirement by requirement, which have passing tests, which have failing ones and which have none. The ISTQB Foundation syllabus lists what good traceability makes possible: evaluating coverage, determining the impact of changes, facilitating audits, helping meet IT governance criteria, and making test reports understandable to stakeholders.

For the tester it is also protection. When a requirement changes two days before a release, traceability turns "what do we need to retest?" from a debate into a lookup. When a defect escapes to production, the links show whether the requirement was never tested or was tested and the test missed the problem — two very different lessons for the team.

What traceability links, and what each link answers

Traceability follows the chain of work products from the test process: a requirement or acceptance criterion in the test basis, the test conditions derived from it, the test cases that cover them, their results on a build, and the defects reported from failures. Every item needs a stable, unique id, and each link is recorded on the item itself: a test case names the requirement it covers, a defect report names the test case and the requirement. The syllabus also counts risks among the testware to link: tracing test results to the risks they address shows how much risk is left.

Links are many-to-many. One requirement usually needs several test cases, and one end-to-end test case can cover several requirements. A link means "this test checks this requirement", not "this test passes through this screen".

• Requirement → test cases: is this requirement tested at all, and by which tests?
• Test case → result: did those tests pass on the build we plan to release?
• Result → defect: which open defects stand between this requirement and "done"?
• Test case → requirement: why does this test exist, and who decides its expected result?

Requirements-to-test mapping: the traceability matrix

A requirements traceability matrix (RTM) puts the links in one table: one row per requirement, one column per test case, and a mark where a test covers a requirement. Teams often add the latest result and open defects, or keep the links in a test management tool and produce the matrix as a report. A spreadsheet is enough to start; what matters is that each link is recorded when the test is written, not rebuilt from memory before a release.

The running example of this lesson is the coupon feature of an online shop, with four requirements and five test cases. The "Traces to" field of each test case is the source; the matrix is built from it.

• Trace at the level you test: individual requirements or acceptance criteria, not whole features or epics.
• Write the requirement id into every test case while you design it, and into automated test names or tags.

Requirements
REQ-1  One coupon code per order
REQ-2  An expired coupon is rejected with "This coupon has expired"
REQ-3  A percentage discount applies to the items subtotal, not to delivery
REQ-4  The invoice email shows the discount on its own line

Test cases, each with its [Traces to] field
TC-01  [REQ-1, REQ-3]  Apply a valid 10% coupon to a 200.00 SAR basket
TC-02  [REQ-1]         Apply a second coupon to the same order
TC-03  [REQ-2]         Apply a coupon that expired yesterday
TC-04  [REQ-3]         Apply a 10% coupon: 100.00 SAR basket, 15.00 SAR delivery fee
TC-05  [none]          Enter the coupon code in lower case

Matrix built from those fields
RTM     TC-01  TC-02  TC-03  TC-04  TC-05
REQ-1     x      x
REQ-2                   x
REQ-3     x                    x
REQ-4

Try it: Requirements → Test Cases Try it: Requirements → Test Scenarios

Forward and backward traceability

Forward traceability follows each requirement to its tests, and on to their results and defects. In the matrix you read along a row, and the question is "is everything we promised tested?". In the coupon example the REQ-4 row is empty: nobody tests the invoice email, so no report can claim that REQ-4 works.

Backward traceability follows each test case or defect back to the requirement it comes from. In the matrix you read down a column, and the question is "why does this test exist?". The TC-05 column is empty: a test for lower-case coupon codes that no requirement asks for. Keeping links that can be followed both ways is called bidirectional traceability; a matrix gives you both readings from the same marks. The ISTQB syllabus does not name these directions: forward, backward and bidirectional are common industry terms.

Every gap is a question for the team, not an automatic fix:

• A requirement with no test (REQ-4): design one, or record why it is not tested here — out of scope, covered at another test level, or a risk the product owner accepts.
• A test with no requirement (TC-05): either a requirement is missing — case-insensitive codes may be exactly what the business wants, so ask and get it written down — or the test checks something nobody needs and should be retired.
• A defect that traces to no requirement: often an unwritten expectation; raise it in defect triage so the requirement is added or clarified.

Worked example: impact analysis for a changed requirement

Impact analysis means working out what a change will affect before it is built and released; done early, it can even help decide whether the change should be made. Traceability makes the testing part of it quick and explainable. A month after the coupon feature shipped, the product owner raises change request CR-12: "The coupon discount is capped at 50.00 SAR per order." It modifies REQ-3.

First compare the old and the new wording to see exactly what changed. Then follow the changed requirement forward, read each affected test backward to see what else it covers, decide whether each test stays, changes or is joined by new ones, and ask about what the matrix cannot show.

• The matrix narrowed the work to one requirement, two existing tests that keep their expected results, and three new ones, instead of "retest coupons".
• The matrix could not show the impact on REQ-4: it holds recorded links, not every place the discount is used. Ask the developer which code and screens read the discount.

CR-12: the coupon discount is capped at 50.00 SAR per order (changes REQ-3)

1. Forward from REQ-3: TC-01, TC-04
2. Backward from those tests: TC-01 also covers REQ-1, so any edit must keep that check
3. Review: TC-01 gives a 20.00 discount and TC-04 a 10.00 discount, both below the cap.
   Both expected results stay unchanged.
4. New tests for REQ-3:
   TC-06  10% of 400.00: discount 40.00 (below the cap)
   TC-07  10% of 500.00: discount 50.00 (at the cap)
   TC-08  10% of 800.00: discount 50.00, not 80.00 (above the cap)
5. Beyond the matrix: REQ-4 (invoice email) must show the capped amount and still
   has no test, so add TC-09. Ask the developer which other code reads the discount.
6. Run TC-01, TC-04 and TC-06 to TC-09 on the new build, plus the regression tests the
   team selects, and add the new links to the matrix.

Try it: Text Diff Try it: Regression Scenario Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.