How WalnutAI Maps Test Cases to User Stories
Every test case WalnutAI generates links back to the user story or requirement it covers, automatically, without anyone building or maintaining that link by hand. Most teams only notice this matters the week before an audit or a release gate review, when someone asks, "can you prove every requirement in this release has been tested" and the honest answer used to require days of spreadsheet archaeology. Here's what that link actually looks like, how to read it, and how to put it to use before you're the one being asked that question.
What Traceability Data Actually Looks Like
WalnutAI's Requirement Traceability Matrix (RTM) is an interactive graph, not a static spreadsheet. It maps the full chain: Epic, to Feature, to User Story, to Test Case, to Defect, as an interactive D3.js visualization with color-coded nodes for each level. Stories imported from Jira or Azure DevOps, test cases generated or created manually, and defects logged against test runs are all connected automatically as the project evolves. There's no matrix to update by hand and nothing to fall out of sync, because the graph is built from what's actually happening in the project, not from a snapshot someone remembered to refresh.
How to Read the Traceability Map
Open the RTM view for your project. The graph loads with every Epic as a starting node, giving you the full shape of the release before drilling into any one part of it.
Read the node colours to identify the level. Epics, Features, User Stories, Test Cases, and Defects are each color-coded, so you can tell at a glance what type of item you're looking at without opening it.
Click any node to open its detail panel. Clicking a Story shows its acceptance criteria and every Test Case linked to it. Clicking a Test Case shows its execution history and any linked Defects. You can move up or down the chain from any point.
Drag and zoom to navigate larger releases. For an Epic with dozens of Stories, the graph stays navigable, letting you zoom into one Feature's worth of detail without losing the surrounding context.
Trace a single requirement end to end. Starting from one User Story, follow its connections down to every Test Case that covers it, and from there to any open Defects, to see the complete state of that one requirement in a few clicks.
How to Use It to Identify Gaps
A gap shows up in the RTM as a dead end, literally. A User Story node with no Test Case connected to it is a requirement with zero coverage, visible immediately rather than discovered during a manual review. Filtering the graph by a specific Epic or Feature root narrows the view to exactly the area you're worried about, so a QA lead reviewing one feature before release doesn't have to scroll through the entire project to find what's missing.
The RTM shows coverage gaps, whether a story has a linked test case or not. WalnutAI's gap analysis engine goes a layer deeper on the same data, semantically comparing what a story's acceptance criteria actually require against the code implementing it, which catches cases where a test case exists but doesn't actually validate what the story asks for. Used together, the RTM tells you what's connected, and gap analysis tells you whether what's connected is actually correct.
How to Use It Before a Compliance Audit or Release Gate Review
Research from the International Software Testing Qualifications Board found that teams maintaining traceability matrices by hand spend an average of 6 to 10 hours per sprint keeping them current, time that mostly goes toward the exact spreadsheet reconciliation this replaces. Because WalnutAI's RTM is maintained automatically that work doesn't happen at all, and teams have reported getting roughly 8 hours back per sprint that used to go into manual updates.
Filter to the scope of the audit or release. Narrow the graph to the specific Epic, Feature, or Story root that the audit or release gate actually covers, rather than exporting the entire project's history.
Export to Excel in one click. The filtered view exports directly to a compliance-ready spreadsheet, showing every requirement, its linked test cases, execution status, and any associated defects.
Attach it as evidence. Because the export reflects the live state of the project rather than a manually assembled snapshot, it stands as documented evidence of requirements coverage without anyone needing to reconstruct it after the fact.
For a release gate review specifically, this means walking into the meeting with a filtered report showing every story in scope, its test coverage, and its defect status, instead of assembling that picture from three different tools the morning of.
See what a live traceability map looks like on your own project: explore the Requirement Traceability Matrix, or start a free trial to generate one from your own backlog.
