Skip to main content
TestPulse adds a read-only “Test coverage” tab to a User Story / PBI work item. It is auto-placed and mounts when you open the tab — no configuration, and it never writes to your data. It answers a sharper question than a coverage percentage: not just “is this story covered?” but “does it pass — and where can I dig?”

​
The headline

At the top, two pills load instantly:
  • Coverage — are there linked test cases, and how many?
  • Depth — do those tests have real steps, or are they shallow / underspecified? An advisory, AI-free signal — never blocking.

​
Execution verdict

A colour-coded banner reduces all the outcomes below to a single answer:

Passed

Every test passes in the current scope.

Not OK

At least one test failed.

Not Run

Nothing failed, but some tests have not run (Blocked / Not Applicable count as Not Run).

Not covered

No linked test — a neutral state.
Precedence is strict: any Failed leads to Not OK; otherwise any non-passed result leads to Not Run; only 100% Passed gives Passed (there is no “partial”). It always shows an icon + label (never colour alone) and never recolours the Coverage pill — coverage and execution stay distinct axes.

​
Scope selector

The scope selector is shown whenever the story is covered — so you always know the results are the latest execution.
Choose the scope of the pass/fail:
  • Latest (all plans) — the default.
  • A specific plan · configuration — each scope option is labelled with its configuration when one is known (e.g. “SPRINT 5 · QUAL_IT”); it re-frames status, failures and freshness to that plan, and masks the tests that are not in it (with an “X of N in this plan” line).
It is remembered per work item, switches instantly in memory (no new read), and the execution verdict re-computes with it. When a specific plan is framed, a Run in Azure DevOps link next to the selector opens that plan’s execution view. Coverage, Depth and the bug list stay plan-independent — a bug binds to a test case, not a plan. When one test case covers several sibling stories that differ only by configuration, the last run is resolved from this story’s own requirement-based suite — you see your configuration’s result, never a sibling’s more recent run. Stories without a requirement-based suite keep the previous “latest across configurations” behaviour.

​
Clickable test IDs

Each linked test shows a clickable #ID that opens the test case in a new tab — no hunting through plans and suites.

​
The results table

For each linked test: its #ID, title (with its type tag), outcome, last run date, and the bug behind a failure — or a failing-with-no-defect flag when a test fails without a linked bug. All five columns sort — click a header to sort, click again to reverse — and the sort is remembered per work item (failures first by default). When a test has a recorded run, its Last run cell opens the exact result in Azure DevOps, and each row can open the exact executed suite — no blank plan page. A story modified after its tests last ran carries a “Modified after last run” badge — its green results may no longer prove anything. A Show detail button expands it to list the business fields changed since that run — Acceptance criteria, Description, State, Priority, Iteration, Tags, Title — as before → after, with added wording highlighted on rich fields, a feeds depth analysis marker on Acceptance criteria / Description, and any attachments added or removed. The revision read is lazy and opt-in — nothing is fetched until you expand. See Requirement Drift & stale coverage.

​
What it does not do

  • Read-only. No writes, no new scope, no new dependency. The only extra network call is the lazy revision read behind Show detail — fetched once, on demand, never on load.
  • It never writes to your data and never reads comments.
  • Live and independent of published reports — it reuses the same depth / status / failure engines.

Concepts: statuses & results

How outcomes are read and reduced.

Quality Gate & GO/NO-GO

Turn results into a release decision.