Skip to main content
TestPulse reports the latest result of each test and reduces them to a single execution verdict. Here is exactly how.

​
Outcomes

​
The “latest result”

A test point can have a history of results. TestPulse takes the most recent one (by completion date) — that is the outcome and the last run date you see. Change the scope and the latest is recomputed for that plan, in memory, with no new read.

​
From outcomes to a verdict

The execution verdict is a pure reduction with strict precedence:
  1. Any Failed → Not OK
  2. Otherwise any non-passed (Blocked, Not Applicable, Not Executed, None) → Not Run
  3. Only 100% Passed → Passed
  4. No linked test → Not covered
There is no “partial”: one failure is enough to make a story Not OK. The verdict always shows an icon + label, so it reads correctly in light or dark themes and for colour-blind users, and it never recolours the Coverage pill.
None vs Not Executed: None means the point has no result object at all; Not Executed means a result exists but the run hasn’t happened. Both read as Not Run.

​
Unstable tests

A test is flagged unstable when its outcome flips between consecutive runs often enough to cross your configured threshold. Only real executions count — Passed, Failed, Blocked, Inconclusive. Blocked is an execution: the tester tried and recorded an obstacle. None and Not Executed are absences of execution, and an absence cannot be a flip: a test run once, preceded by a point that was never executed, is no longer reported as 100% unstable. A case needs two genuine executions before instability means anything at all.
The same calculation and the same threshold now drive every surface — the report tab, the notification, the executive summary, the HTML export and the PDF. Before v2.51.0 two of them used a hardcoded threshold, so the same report could call a test unstable in its PDF and stable in its notification.

​
Full history

The Full history tab lists every result TestPulse could read, one row per execution, each carrying its run number — so a row can be traced straight back to Azure DevOps. You may see more rows here than Azure DevOps shows on the test point itself. Both are right: Azure DevOps hides runs that published no outcome, TestPulse keeps them, marked None. Hovering that status says so explicitly. The instability calculation ignores them, which is why a case can show, say, nine history rows and five runs.

The Test coverage tab

Where the verdict appears.

Traceability & hierarchy

The bug behind a failure.