Coverage

Introduction

What is the Coverage screen?

The Coverage screen — titled Traceability, Coverage & Requirements in the page header — answers one question: how well do my test cases cover my requirements, and how much of that is automated? It is not a single number on a single chart. It is a workspace with four tabs that follow the chain from a requirement (a thing the product must do, usually pulled out of a source document) down to the test cases that verify it, and further down to the test scripts (real files on disk) that automate it.

Critically, this screen measures coverage at three distinct levels, so read each metric carefully:

• Requirements coverage — are your requirements linked to at least one test case? (the Traceability and Orphan tabs)
• Automation coverage — of the test cases that exist, how many are actually automated by a script? (the Coverage Dashboard’s headline number)
• Source coverage — of your source documents, how many have produced test cases at all? (the Coverage Dashboard) Analogy. Think of a building inspector’s checklist. The requirements are the items the inspector must check (fire exits, wiring, plumbing). The test cases are the inspections written up for each item. The test scripts are the inspectors who actually walk the site. This screen is the inspector’s clipboard: it shows which checklist items have an inspection assigned (traceability), which inspections actually have someone walking the site (automation), and which checklist items nobody is looking at (orphans/gaps).

Note

In one sentence: the Coverage screen maps requirements -> test cases -> test scripts, then reports what percentage of test cases are automated, what percentage of sources produced tests, and which requirements, test cases, scripts, and sources are left dangling with nothing linked to them.

Who this guide is for

• QA leads and test managers who need to prove the test suite covers the spec, and to find requirements with no tests before a release sign-off.
• Automation engineers who want to see which test cases still run manually and which test scripts on disk are not yet tied to a test case.
• Product owners / BAs who want assurance that every requirement extracted from a PRD or Jira ticket has been turned into verifiable tests.
• Anyone auditing the project who needs an exportable traceability matrix for a compliance or release record. No coding is required to read this screen. Generating the underlying requirements and test cases is done elsewhere (in AI Test Gen, from Sources); this screen reports on the result.

Key terms

Term	What it means here
Requirement	A single thing the product must do. Requirements flow in automatically from Sources via the AI extraction pipeline; they are read-only on this screen (you cannot type a new one here). Each carries an External ID (e.g. REQ-001), title, priority, and source.
Test case	A documented test that verifies one or more requirements. A test case can be linked to a requirement on the Requirements tab, or generated against it from a source.
Test script	An actual automation file on disk (e.g. a Playwright or Cypress spec). A test case is considered automated when it is mapped to a script.
Source	A document the requirements/tests were derived from (PRD, Jira ticket, NLP prompt, uploaded file). Shown with a type icon: Requirement, NLP, JIRA, or Document.
Linked / Unlinked	Linked = a relationship exists (requirement<->test case, or test case<->script). Unlinked items are the ones this screen flags as gaps.
Orphan	An item with nothing on the other side of its expected link: a test case with no requirement, a script with no test case, or a source that produced no test cases.
Strategy	A test-design technique a generated test belongs to (happy-path, negative, boundary, equivalence, error-handling, security, performance, accessibility, compatibility, integration, data-validation). Drives the heatmap columns in the Document view.
Persona	A user role a generated test was written for. Optional; only appears when the source’s tests carry persona metadata.
Coverage level	Per-requirement verdict: Fully Covered (green), Partially Covered (amber), or Not Covered (red).
Matrix fill	Of all possible requirement x test-case cells in the grid, the percentage that are actually linked. A density measure, not a pass-rate.

How it works

Every number on this screen is computed by the backend from data you create elsewhere. Nothing here is hand-entered.

• Requirements are extracted from Sources by the AI pipeline and arrive as active by default. The Requirements tab is read-only at the requirement level — there is intentionally no ”+ New Requirement” button.
• Test cases come from AI Test Gen (generated against a source) or are linked manually on the Requirements tab.
• Scripts are discovered by scanning the project directory; the Unmapped Test Scripts list reflects real test files found on disk that no test case claims.
• The Coverage Dashboard pulls a single coverage-stats object (automation %, source %, per-priority automation, per-type counts) and an orphans object.
• The Document view matrix is fetched per-source and is built from saved test cases that persisted requirement_id + strategy metadata at generation time. Older tests without that metadata are counted as legacy uncategorized.

Tip

If a number looks wrong, the fix is almost always upstream: add or re-scan a Source, or re-generate test cases in AI Test Gen so the requirement_id/strategy metadata is saved.

Getting Started

Opening Coverage

1. From the left navigation, open the Traceability, Coverage & Requirements entry (route /coverage).
2. The page opens on the Requirements tab by default.
3. Switch tabs using the four tab buttons under the header: Requirements, Traceability Matrix, Coverage Dashboard, Orphan Detection.
4. The active tab is remembered in the URL (the tab query parameter), so you can bookmark or share a link straight to, say, the Coverage Dashboard.

Note

The Traceability Matrix tab has a second URL parameter, subtab, with values document (Detailed View) and list (List). This too is bookmarkable.

The screen layout

Area	Where	What it does
Page title	Top-left, with a target icon	Reads Traceability, Coverage & Requirements with the subtitle “Track requirement coverage, manage traceability, and find orphan items”.
Export Matrix button	Top-right of the header	Exports the coverage matrix to XLSX (see the Export section).
Tab bar	Below the header	Four tabs: Requirements, Traceability Matrix, Coverage Dashboard, Orphan Detection. Active tab has a colored underline.
Tab content	Main body	Changes with the selected tab — table, matrix, metric cards, or orphan lists.

At a glance

If you only have thirty seconds, do this:

• Open Coverage Dashboard -> read the Automation Coverage % (green). That is your headline.
• Glance at the three orphan counters (Orphan Test Cases, Orphan Test Scripts, Orphan Sources). Any non-zero number is a loose end colored amber/orange/purple.
• Open Orphan Detection to see exactly which items those counters point to.

Requirements Tab

This tab lists every requirement and lets you attach test cases to them. It is the foundation the other three tabs measure against.

Controls. A Search requirements… box and an All Priorities dropdown (Critical / High / Medium / Low) filter the list. There is deliberately no create button and no status filter — requirements arrive from Sources as active, so those affordances were removed.

Column	Meaning
(chevron)	Click any row to expand it and reveal its linked test cases.
External ID	The requirement’s source identifier (e.g. REQ-001); falls back to the internal id.
Title	The requirement statement.
Priority	Color-coded badge: Critical red, High orange, Medium amber, Low emerald.
Source	Where the requirement came from (Jira, Confluence, PRD, etc.), or -.
Linked TCs	Count of test cases attached to this requirement.

Expanding a row shows the Linked Test Cases panel: each linked test case with its id, title, and priority, plus an unlink (broken-chain) icon to detach it. A Link Test Cases button opens a modal with a search box and checkboxes to attach one or more existing test cases at once.

Note

If the list is empty you will see “No requirements found — Requirements are derived from Sources via AI Test Gen. Add a source and generate test cases to populate this list.”

Traceability Matrix Tab

This tab maps the full chain Source Document -> Content Sections -> Test Cases. A view toggle at the top-right switches between Detailed View (document-grouped, the default) and List (one row per requirement).

Reading the summary cards

Card	Meaning
Requirements	Number of requirements in the matrix.
Test Cases	Number of distinct test cases referenced across all requirements.
Links	Total requirement<->test-case links (shown in brand color).
Matrix Fill	Links divided by total possible cells (requirements x test cases), as a percent. A density figure — low is normal and not necessarily bad.

Caution

Matrix Fill is easily misread. It is NOT a pass rate and NOT requirement coverage. A small fill % just means each requirement is linked to only a few of the many test cases — which is expected. Use the per-requirement Coverage column (List view) for the real coverage verdict.

Detailed View

Detailed View lists each source document as a collapsible card. The card header shows the source title, file name, count of generated test cases, any manually-linked count (amber), and a coverage percent with a colored progress bar:

Coverage %	Color
80% and above	Green (emerald)
50% to 79%	Amber
Below 50%	Red

Expanding a source card renders the Requirement x Strategy heatmap (the DocumentRequirementMatrix). Rows are requirements; columns are test-design strategies, abbreviated in the header — HP happy-path, NEG negative, BND boundary, EQ equivalence, ERR error-handling, SEC security, PRF performance, A11Y accessibility, CMP compatibility, INT integration, DV data-validation. Hover a column header for the full name.

Cell appearance	Meaning
Green checkmark + a number	That requirement has that many test cases for this strategy.
Dim hollow circle	No tests for this strategy on this requirement (a gap).
Per-row score %	Covered strategies divided by strategies seen for the source — a per-requirement coverage score.
Last Gen column	Relative time since the requirement’s tests were last generated (e.g. “3h ago”).
Tests column	Total test cases for that requirement row.

Heatmap controls (above the table): a Search box (matches requirement title, source quote, requirement id, or test-case titles); a sort dropdown (Recently generated / Least covered first / Highest priority first / Most tests first / Fewest tests first); an Uncovered only checkbox (shows only requirements that have at least one strategy with zero tests); Per-persona columns checkbox (adds one column per persona, only offered when the source has persona data); Priority filter chips (Critical/High/Medium/Low); and Persona filter chips. A “Showing X of Y requirements” line and a Clear filters link round it out.

Drill-down. Click any row label (the chevron) to expand it inline. The expansion shows one card per strategy listing every test case (id, title, priority badge, persona badge); each test links to /test-cases?tcId=<id>. A special amber Manually Linked row appears at the bottom when the source has test cases attached by hand from the Requirements tab — those carry no strategy/persona metadata, so their taxonomy columns read “(no taxonomy data)”.

Note

If a source’s tests predate the metadata feature, you will see ”(+ N legacy uncategorized)” and a prompt to re-generate via AI Test Gen to populate the matrix.

List View

List View flattens everything to one row per requirement with these columns: Requirement (priority badge + title + id), Linked Test Cases (color-coded chips), Count, Result, and Coverage. A legend at the top decodes the chip colors.

Signal	Color	Meaning
Test-case chip / Passed	Green (emerald)	Latest execution of that test passed (shown with a check).
Test-case chip / Failed	Red	Latest execution failed (shown with an X).
Test-case chip / Not Run	Gray	Never executed (shown with a dot).
Row tint — green	Emerald wash	Requirement is Fully Covered (has tests and all passed).
Row tint — red	Red wash	Requirement has no test cases linked (a hard gap).
Coverage badge	Green / Amber / Red	Fully Covered / Partially Covered / Not Covered.

The Result column rolls the linked tests into one verdict: Failed if any linked test failed, Passed only if every linked test passed (and there is at least one), otherwise Not Run. Coverage is none when no tests are linked, full when the rolled-up result is Passed, and partial otherwise.

Coverage Dashboard Tab

This is the metrics tab — five stat cards on top, then two breakdown panels.

The stat cards

Card	Meaning	Color
Automation Coverage	Percent of test cases that are automated (mapped to a script). The headline metric.	Green % with a green progress bar
Source Coverage	Percent of sources that have produced test cases.	Purple % with a purple progress bar
Orphan Test Cases	Count of test cases not linked to any requirement.	Amber if > 0, gray if 0
Orphan Test Scripts	Count of mapped scripts whose test case no longer exists (broken script links).	Orange if > 0, gray if 0
Orphan Sources	Count of sources with zero test cases via any path (generated or manually linked).	Purple if > 0, gray if 0

Tip

The three orphan cards mirror the lists on the Orphan Detection tab exactly — they are the quick-glance version. A gray zero on all three means no loose ends.

Automation by priority

A horizontal-bar panel. For each priority that has test cases, it shows automated / total and the percent, with a bar filled to that percent. Priorities are ordered Critical -> High -> Medium -> Low and bar-colored rose (critical), orange (high), amber (medium), emerald (low). Priorities with no test cases are hidden; if there are none at all it reads “No test cases yet.”

Caution

Read this as automation per priority, not pass-rate. A 100% bar on Critical means every critical test case is automated — it says nothing about whether those tests passed.

Test cases by type

A set of colored pills, one per test-case type that has at least one case, each showing the type name and its count, e.g. Functional (12), Regression (5). Type colors: functional sky, regression violet, smoke amber, integration teal, e2e indigo, api cyan, performance rose, security red. If there is no data it reads “No type distribution data available.”

Orphan Detection Tab

This tab is the gap list — “Find unlinked items that may need attention.” It has three sections, each with a count badge (colored when non-zero) and an all-clear empty state when there is nothing to fix.

Orphan test cases

Test cases not linked to any requirement. Columns: Title (with mono id), Type (colored badge), Priority badge, Created date. Empty state: “No orphan test cases — All test cases are linked to requirements.”

Requirements without coverage

This section merges two related problems in one table:

Status pill	Meaning
Not Mapped (amber)	A test file found in the project directory that no test case claims. Columns: Script Path, File Name, Framework, Status.
Orphaned (red)	A previously-mapped script whose test case no longer exists — a broken link. Shown on a faint red row tint.

Empty state (only when both lists are empty): “No unmapped scripts — All test scripts in the project are mapped to test cases.”

Orphan sources

Sources with no generated or manually-linked test cases. Columns: Title, Type (with an emoji label: Requirement, NLP, JIRA, or Document), Created. Empty state: “No orphan sources — All sources have been used for test generation.”

Filters & Grouping

Where	Control	Effect
Requirements tab	Search box + Priority dropdown	Filter the requirement list by text or priority.
Requirements tab	Row chevron	Expand to see / link / unlink test cases.
Traceability tab	Detailed / List toggle	Switch between per-source heatmap and per-requirement table (stored in subtab).
Traceability — Detailed	Source card chevron	Expand a source to load its Requirement x Strategy heatmap.
Heatmap	Search / Sort / Uncovered only / Priority & Persona chips / Per-persona columns	Narrow and reorder the requirement rows; surface gaps.
Heatmap	Row chevron	Inline-expand a requirement to list its test cases grouped by strategy, each linking to the test case.
Coverage Dashboard	(none)	Read-only metrics; click into Orphan Detection for the underlying items.

Exporting

There are two independent export paths:

• Export Matrix (header button, all tabs) — produces an XLSX of the coverage matrix via the backend document generator (type coverage-matrix).
• Export CSV (inside an expanded source’s heatmap) — a client-side CSV built in the browser, no backend needed. Columns: Requirement ID, Title, Source Quote, Total Tests, Last Generated, one count column per strategy, one count column per persona, and a flat list of test case IDs grouped by strategy. The file is named coverage-matrix_<source-title>.csv.

Tip

Use Export Matrix (XLSX) for a release/audit record of the whole project; use the per-source Export CSV when you only need one document’s requirement-by-strategy breakdown.

Common Tasks (How Do I…?)

I want to…	Do this
See my overall automation level	Coverage Dashboard -> read Automation Coverage (green %).
Find requirements with no tests	Traceability Matrix -> List view -> look for red-tinted rows / Not Covered badges.
Add a test to a requirement	Requirements tab -> expand the requirement -> Link Test Cases -> check tests -> Link Selected.
Remove a wrong link	Requirements tab -> expand requirement -> click the unlink (broken-chain) icon.
See which strategies a requirement is missing	Traceability -> Detailed -> expand the source -> find dim hollow-circle cells, or tick Uncovered only.
List every test for a requirement	In the heatmap, click the requirement’s row to expand it; tests are grouped by strategy.
Find test scripts on disk with no test case	Orphan Detection -> Unmapped Test Scripts (amber Not Mapped rows).
Find sources that produced nothing	Orphan Detection -> Orphan Sources, or the dashboard’s Orphan Sources card.
Export for an audit	Header -> Export Matrix (XLSX); or per-source Export CSV in the heatmap.
Jump from a matrix cell to the test case	Expand the row, then click any test in the strategy card (opens /test-cases?tcId=…).

Tips & Best Practices

• Chase the orphans first. The three orphan counters are your fastest signal of disorganization; aim to get them to gray zeros before a release.
• Don’t confuse Matrix Fill with coverage. A low fill % is normal. Judge real coverage from the per-requirement Coverage badges and the per-source coverage %.
• Automation % is not a quality score. It tells you how much is scripted, not how much passed — check the List view’s Result column for that.
• Re-generate legacy tests. If you see “legacy uncategorized,” re-run AI Test Gen so tests carry requirement_id/strategy metadata and light up the heatmap.
• Use Uncovered only + sort by Least covered first to triage the weakest requirements quickly.
• Keep scripts mapped. An Orphaned (red) script means a test case was deleted out from under a mapping — clean those up to keep automation counts honest.
• Bookmark a tab/subtab. The tab and subtab URL params let you deep-link teammates straight to, e.g., the List view.

Troubleshooting & FAQ

Symptom	Likely cause / fix
”No requirements found”	No requirements have been extracted yet. Add a Source and run AI Test Gen — requirements cannot be typed in here.
A source shows 0% coverage but has tests	Its tests may be manually-linked or legacy (no strategy metadata). Expand the source; check for the amber Manually Linked row or a legacy note, and re-generate to populate the heatmap.
Heatmap is empty for a source	Either no saved tests, or only legacy tests without requirement_id/strategy. Use the Open AI Test Gen link to re-generate.
Matrix Fill % looks alarmingly low	Expected — it is link density across all requirement x test-case pairs, not coverage. Use the per-requirement Coverage badges instead.
Automation Coverage stuck at 0%	No test cases are mapped to scripts yet. Map scripts to test cases (or generate automated tests) to raise it.
Orphan Test Scripts count is non-zero	A mapped script’s test case was deleted, leaving a broken link. Find it under Orphan Detection -> Unmapped Test Scripts (red Orphaned rows) and re-map or remove it.
A real test file isn’t listed anywhere	If it’s mapped it won’t appear as orphan; if unmapped it should appear under Unmapped Test Scripts after the project is scanned. Re-scan the project if it’s missing.
Persona chips/columns don’t appear	The source’s tests carry no persona metadata; the persona controls only render when persona data exists.
Export Matrix does nothing	The XLSX path needs the backend document generator; if it fails, use the per-source client-side Export CSV instead, which has no backend dependency.
Counts differ between Dashboard and Orphan tab	They shouldn’t — both read the same orphans source. Refresh; the dashboard cards mirror the Orphan Detection lists by design.

Related

• Sources — where requirements come from.
• Test Cases — what’s covering them.
• AI Test Gen — generate cases for uncovered requirements.