Skip to main content

​
While it runs

Three things update live.
  • The browser panel shows screenshots of the real page, roughly twice a second.
  • The execution bar lists the steps, each turning from pending to running to passed, failed or skipped.
  • The chat receives the report when the run ends.
You can stop a run at any point with Stop the test. Stopping closes the browser at once, keeps the steps that ran, and stores the run as Cancelled. See Browser runs. Closing the tab does not stop the run. It finishes and stores its report.

​
The report

The report opens with the step counts:
Those counts come from the steps, not from prose. The write-up is forbidden from stating its own numbers, because a narrated count that disagreed with the steps is how a broken test reads as a healthy one. Below that, a walkthrough, and a Result line: Passed, Failed, or Needs review with the reason. Run status explains how that is decided. What the walkthrough quotes is what was observed:
  • the state read back off the element after an assertion: enabled, the text it actually held, the value in the input, or not present
  • the address the page was on when the step acted, when the app moved it mid-step
  • the network call a step’s API assertion matched, with its status
And what it does not do: infer an attribute nobody looked at, or claim the site failed because a step could not find an element. Under the latest report, How was this run? asks for a rating. It is optional, and you can turn it off.

​
Why a step failed

Each failed step carries a cause, and the report describes it accordingly. Debugging a failed run walks through each of these.

​
The run page

Every run has a permanent page at /runs/<run-id> holding more than the chat report shows:
  • Every step, with its value or condition, the value read back, expected and actual for assertions, the verdict and the time
  • The final screenshot, and a screenshot at the moment of each failed step
  • Console messages and network requests captured during each step’s window
  • Accessibility findings from the scan of the finished page
  • Performance metrics for each page that loaded, and any budget breach
  • Visual diffs (baseline, actual and difference side by side) for steps with a baseline
  • The recording and the trace, in one Artifacts section that also says why any of them is missing
The recording and the other artifacts finish saving a little after the run completes. Until they do, the page says so and refreshes by itself.

​
Sharing a run

Share on a run page mints a public link. It is a 128-bit token, with an expiry of 1, 7 or 30 days or none, and you can revoke it at any time. The page it serves is sanitised: no cookies, no environment headers, no browser storage state, no console or network detail. Anyone with the link can read the report and watch the recording without a Testorim account.

​
Runs in flight

On pages other than the Test tab, a small N active runs pill in the bottom-right corner opens into the runs in progress across the workspace, grouped by batch. Each has a stop button that asks before it cancels. Hiding the pill cancels nothing; it comes back when another run starts.

​
Saving the run as a procedure

Save as procedure, under the report in the chat, turns the run into a procedure that replays without planning. Give it a name and save. What gets saved is what actually worked, not what was planned: if an Enter key did nothing and the run recovered by clicking the field’s own button, the saved step is that click. If a typed value was committed by a combobox, the saved step is the selection. If a click was skipped because the page was already there, nothing is saved for it. Passwords the run typed are saved encrypted, so the replay can type them, and every view of the procedure shows ***. Coverage-gap placeholders are stripped on save: a placeholder for a check the planner could not fit has no business in a test you replay every night.