Using qTest's Requirement Traceability Matrix to Find Coverage Gaps Before Release

Your release review is tomorrow, and the product owner asks a simple question: which of the 40 stories in this sprint actually have test coverage? If your answer involves exporting a spreadsheet and eyeballing rows, qTest's built-in Requirement Traceability Matrix (RTM) is the feature you should be using instead. It links requirements, test cases, and defects in one live view and highlights uncovered requirements and orphaned tests automatically — provided your team maintains the links.

Note up front: the full RTM view is an Enterprise-tier feature in qTest, and exact menu names and licensing boundaries change between versions. Verify the steps below against your own instance before relying on them in a process document.

What the RTM actually shows you

The RTM is a generated matrix: requirements on one axis, linked test cases on the other, with execution status (passed, failed, blocked, not run) rolled up from your test runs. Because the links are bidirectional, the same data answers two questions:

• Forward traceability: does every requirement have at least one test case, and what is its current status?
• Backward traceability: is every test case tied to a requirement, or are you running tests nobody asked for?

Defects linked to failed test cases also surface in the chain, so you can trace a requirement all the way to the open bug blocking it. The matrix updates as executions are logged — it is a live view, not a report you regenerate.

A worked example: the password-reset story

Say your sprint includes the story "As a user I can reset my password." A minimal, honest coverage set is three test cases:

1. Valid reset request — email sent, token accepted, password changed.
2. Invalid or tampered token — reset rejected with a safe error.
3. Expired link — user is prompted to request a new token.

In qTest, a user with Requirements and Test Management permissions would:

1. Create the requirement under the Requirements module (or import it from Jira if the integration is configured).
2. Create the three test cases in Test Design.
3. Open the requirement's Traceability tab and link each test case. Links can also be created from the test case side, or bulk-created via import.
4. Navigate to the Requirement Traceability view (typically under Tracking/Reports — the exact location varies by version) and filter to the sprint's release or the specific requirement.

The matrix should now show the story with three linked test cases. Run the tests in a test cycle, and the cells reflect the latest execution status. If only two of the three pass and the expired-link case is blocked, the requirement's rolled-up status makes that visible without opening a single test run.

Verifying the matrix is telling the truth

Before you present RTM numbers to stakeholders, sanity-check them:

• Filter the matrix to one requirement you know well and confirm the linked test cases match what you expect — no missing links, no extras.
• Look specifically for requirements with zero linked tests and test cases with zero linked requirements. Both lists are the feature's real value.
• If your edition supports it, export the matrix (e.g., to Excel) and confirm the exported requirement–test-case pairs match the on-screen view. A mismatch is a red flag worth raising with your qTest admin.

The trade-off: the matrix is only as good as your linking discipline

The RTM does not infer coverage — it reports the links your team created. If testers add test cases without linking them, the matrix shows false gaps, and once stakeholders catch one wrong number, trust in the whole metric collapses. Two mitigations work in practice:

• Make "requirement linked" part of your test case review checklist, the same way you'd check steps and expected results.
• Review the orphaned-tests list at sprint end; it takes minutes and catches most drift.

There is also a performance caveat: on projects with thousands of requirements, rendering the unfiltered matrix can be slow. Always filter by release, sprint, or module before opening the view — treat the unfiltered matrix as an export-and-archive artifact, not a working screen.

Where to start this week

Pick one requirement from your current sprint, link its test cases, and open the RTM filtered to that requirement. If the statuses match what your test runs show, extend the practice to the rest of the sprint backlog. The feature pays off fastest not as an audit artifact, but as the answer to the release-review question you would otherwise spend an afternoon assembling by hand.