Skip to main content
The heart of an exploratory session is turning what you see into something actionable: a captured screen, annotated, attached, and — when it’s a defect — a bug with repro steps already written.

​
Paste a capture of any screen or app

Press Ctrl+V to paste a screenshot of any screen or application — take it with Win+Shift+S, which also works for desktop apps, with nothing to install. Separate files (a Win+G video, a log…) attach by drag & drop or through the Browse… button, which opens the native picker. The drop zone carries an icon, a title and that button; while you drag a file, the whole timeline panel becomes the target, so releasing anywhere on it works. A file released beside the panel is swallowed — the browser will not open it in the tab and take your session off screen. No type filter is applied: the size limit is Azure DevOps’s to enforce. Several files can be dropped at once. They upload one after another, with a progress line showing the rank, the total and the name of the file being sent. If one is refused, the others stay attached and the message names the one that failed, with Azure DevOps’s own wording — nothing is rolled back.

​
Annotate before it’s attached

Each capture opens in an annotation editor: arrow, rectangle, text, highlighter, and a blur to mask sensitive data. The blur is destructive on flatten — once applied and attached, the masked pixels are gone, not just hidden — which is exactly what you want for anything confidential. Since v2.59.0 the blurred region is rendered live as you draw it, by the very same painter that produces the final image — you check the mask before validating it, instead of trusting a dashed frame. That frame remains as a drag indicator while the mouse button is held. You get two explicit colours and can undo the last stroke. The capture is attached to Azure DevOps only when you validate it; cancelling the editor uploads nothing.
Because the blur is destructive, a masked screenshot leaves your machine already redacted — the original pixels never reach Azure DevOps.

​
Create a bug, task or test case

From the session, raise a work item without leaving the screen:
  • Bug — two fields to fill (title pre-filled with your last note, plus severity); everything else is injected, visible and editable: repro steps generated as HTML from your notes, your captures as checkboxes, links to the story and the session, and the inherited classification with a collapsed override.
  • Task and Test case — the same flow, with optional steps generated from your notes.
A capture can also say what it shows: a step to perform, or an obtained result. You choose at capture time — while you still remember why you took it — and can change it afterwards from the timeline. Files are never typed: the distinction only makes sense for a screenshot. That choice shapes the generated test case. The timeline’s own order is kept: each note opens a step, and the captures following it attach to that step rather than to the work item at large. A capture marked as a result fills its step’s expected result with “See screen capture” and turns it into a validation step — the way Azure DevOps itself tells an action from a check. A capture taken before any note has no step to join, so it attaches to the work item alone. Sessions with nothing typed produce exactly the test case they did before. A Test Case created this way reads as “Tests” the story — the direction Azure DevOps shows from the test’s own point of view. Links created before v2.55.0 read the other way round and are not rewritten: only newly created ones changed. Both captures and files dropped onto the timeline are offered for attachment. A piece whose upload can’t be resolved is shown greyed out with the reason rather than quietly dropped from the list. Since v2.59.0 the timeline is no longer append-only while the session is active: a note’s wording or type, and a capture’s caption, can be corrected in place, and an entry can be removed. Removing an entry drops it from your session only — the attachment itself stays in Azure DevOps, and the confirmation says so rather than implying a cleanup TestPulse never performs. An entry tracing a real bug, task or test case can be neither edited nor deleted, and neither can a capture already sent to one. Once the session is closed, nothing is editable: the archived Task is the record.
Since v2.55.0 this panel is also available after a session ends: reopen the session’s tracking Task and the same gesture is there, reading the closed session back from storage.

​
Archive the session

Ending the session archives it as a Task tagged exploratory-session (plus your campaign tag), carrying the full report — charter, duration, counters, timeline — and its relations to the story, the captures and every work item you created. Sessions become natively queryable in Azure DevOps, so a campaign is just a tag query away. Since v2.56.0, a short dialog then offers to assign that Task and give it an initial state — and, since v2.60.0, an optional verdict for the session itself: Passed, Failed or Blocked, nothing preselected. The verdict is final once the session closes, and it is counted nowhere: it never reaches a report indicator or the quality gate. The status list comes from your own work item type’s state categories, so a process that says Terminé shows Terminé; the Removed category is never offered. Since v2.71.0 the dialog also carries a promotion decision block when the session was started on an environment stage — see Promotion decision. Both fields are pre-filled, and Skip bypasses them in one click — producing a Task byte-for-byte identical to the one built before this dialog existed. If your process refuses the requested state, the Task is still created and the session still closes. A separate, non-blocking warning names that one failure using Azure DevOps’ own message, and the transition is never retried.

Explore overview

Start a session and why it’s resilient.

Session report

Turn a finished session into a signed PDF.