Skip to main content
The Cockpit tab is built for the test manager’s morning stand-up: five minutes, four questions — where are we, will the date hold, who does what today, what is blocking. Where the report answers “where do we stand?” at a milestone, the Cockpit answers the stand-up — and it answers first, in one sentence, then justifies. Everything is read-only against Azure DevOps. The only things the Cockpit writes are its own dated snapshots and a target date, stored in Azure DevOps Extension Data like your saved reports — nothing leaves your tenant, and no new permission is required.
TestPulse Cockpit tab with only the test plan selector visible

The Cockpit before a plan is chosen: nothing is computed until you select one.

​
The answer first

With a target date and at least three working days of execution, the headline gives in one sentence:
  • the observed pace — tests per working day, averaged over the last three working days that saw executions;
  • the projected end;
  • the gap to the target, in working days;
  • the pace needed — what remains divided by the working days left.
The target is the plan’s end date; otherwise one you type in the screen — kept for the project, never written to Azure DevOps; otherwise the sentence invites you to set one. Working days are Monday to Friday.
The Cockpit prefers an honest silence to an invented date. With fewer than three working days of history there is no projection, and the sentence says so. A campaign that is finished, not started, without a date or stalled — its last execution too old to extrapolate from — each gets its own sentence rather than a figure.

​
Since the last stand-up

One line: tests run, passed and failed, how many failures are new, bugs opened and resolved, tests unblocked, scope changes — compared with the last snapshot of a previous working day. When that snapshot is not yesterday’s, its date is written. A snapshot captured by an earlier version of TestPulse does not carry what is needed to tell which failures are new or which bugs closed: those items are left out of the line — never shown as zero.

​
Will the date hold?

A full-width burndown in test points (case × suite × configuration): the actual curve, the ideal line, the projection, the target, a this morning mark and the scope changes, annotated on the curve. Scope changes are shown, not smoothed over: adding, removing or resizing a suite or configuration appears as a labelled step. A suite deleted and re-created for the same requirement is reconciled as a re-organisation — matched by requirement only, never by name. A simulator — testers × tests per tester per day, started on what was actually observed — moves the projection. It is session state only, never saved. The pure execution time estimate remains available as secondary information.

​
What to run today, by reason

Tests are grouped by the reason they are there, in this order:
  1. failures to re-run;
  2. tests unblocked since the last stand-up;
  3. high-priority tests never run;
  4. suites behind;
  5. other tests never run.
A test appears only in its first group, the total aims at the pace needed, and each group opens straight in Test Plans. Priority is the requirement’s — through a requirement-based suite or the test case’s Tested By link — otherwise the test case’s own, so a plan without requirement-based suites still knows where to start. A signal that could not be read is stated with its reason, never replaced by a zero.

​
What is blocking

Tests blocked by an open bug (with its age and severity), failures without a linked bug, and tests without a tester. Each line leads to the action.
The Cockpit reads the Tested By links of the test cases, whatever the bug source chosen for reports.

​
Load per tester

A card lists, for each assigned tester, the tests that remain, their observed pace and the end it gives, plus an unassigned batch — with a link to Bulk reassignment. The Cockpit itself reassigns nothing. Testers come from the test points already loaded for the headline: no extra call. Because this card names people and their pace, a project can turn it off in Settings › Cockpit (Show load per tester, on by default). It is a project setting: once off, the card disappears for every member of the project, a discreet line says where it was turned off, and the testers are not even read. The setting shows who last changed it, and when. If it cannot be read, the Cockpit opens with the default.

​
A campaign not yet started

Never an empty screen: the pace needed from day one, the load per tester, where to start, and what each block will show once its condition is met.

​
Details, folded

Progress per suite and the scope journal sit underneath, collapsed. Snapshots are captured once per day per plan whenever the hub is opened or a report generated (the last of the day wins), so the curve stays correct when the perimeter moves. The Cockpit is single-plan.

​
What it reads

No new permission and no new dependency. The only added read fetches the links between the plan’s test cases and their bugs and requirements (with their priorities), in the same grouped work item calls TestPulse already makes — and only after the headline is on screen, so the answer never waits for it.
On a plan with more than 1,000 test cases, those link signals are not read, and the screen says so rather than showing zeros.
Works on Azure DevOps Services and Azure DevOps Server 2022.1.

​
What this screen replaced

Before v2.72.4 the Cockpit ranked What to run today with a weighted score under three profiles — Strict / Standard / Onboarding — alongside KPI tiles and remaining-effort sliders. The profile selector and the scored list are gone: a test now appears because of a reason you can read — it failed, it was unblocked, its requirement is high priority, its suite is behind — rather than a weight. The headline sentence and the simulator took the place of the tiles and sliders. The profile a project had chosen is no longer read, and it is not deleted. Snapshots captured by earlier versions are read as they are, without migration. Reports, exports and the widget are unchanged.

Bulk reassignment

Act on what the load per tester shows.

Quality Gate & GO/NO-GO

From daily steering to the release decision.

Read-only by design

Where snapshots live and what is never written.