1
You describe the workflow
You type one instruction into the project’s Test tab, against the
project’s base address or one of its environments. Optionally you mark it
Should fail (a negative test) or raise the time limit for a slow flow.The run then takes one of the service’s test browsers. When all of them
are busy it waits in line first, and the chat shows its place.If the instruction needs values Testorim cannot invent, such as a real email
and password, it stops and shows you a small form instead of guessing.
2
A plan is written
The planner turns your sentence into an ordered list of steps: navigate,
click, type, assert, select, press, and so on. Each step names its target
in plain language and, for an assertion, a condition from a
closed grammar.Two passes run over the plan before anything executes. A critic drops
assertions too vague to mean anything. A coverage judge then lists any
check you asked for that no step performs; the planner gets one chance to
write the missing check, and anything still uncovered is recorded as a
visible gap rather than silently dropped.A plan may only open the project’s site, the page it is on, or a site you
named in the instruction. A plan that would navigate anywhere else is
refused before it runs, naming the host; name it yourself to proceed.
3
A browser starts
A Chromium browser opens at the project’s address, or at the chosen
environment’s (the project’s default environment when none is named),
with that environment’s headers sent only to its own address.If the project has a saved login state from a login-setup procedure, it is
loaded here, so the run starts signed in.
4
Steps execute, one at a time
For each step, Testorim finds the element, acts on it, waits for the page
to settle, and captures a before/after snapshot.Finding the element has two tiers. Exact matching comes first: a
control whose accessible name is the target, a
<label>, a placeholder,
a test id, a CSS selector you wrote, an explicit ordinal. Anything looser
goes to a grounding model, which is shown the page’s real controls (role,
accessible name, state, the row it sits in) and asked which one the
step means, with your original request as context. If it says none of them,
the step fails and tells you what is on the page.Screenshots stream to your browser throughout.5
The run settles and is measured
After the last step, the page is allowed to settle and performance
metrics are collected. Any visual baselines for the procedure are diffed
as their steps run.
6
A report is written
The report quotes what was observed: the element’s real state, the text
that was actually on the page, the network calls that fired. Never an
attribute nobody looked at. It ends with a structured verdict.The verdict is Passed, Failed or Needs review. Only an
executed step that failed makes a run fail. A run with no failed step
that could not confirm the request (a check never performed, a check that
proved nothing, a report that disagrees) needs review. See
Run status.The run is complete once the report is in. The final screenshot, the
accessibility scan, the recording and the trace finish saving in the
background.
7
You save it, or you do not
A run you are happy with can be saved as a procedure (Save as
procedure), a fixed list of steps that replays without planning it
again. Replays are deterministic, cost less, and are what schedules, the
CLI, and the GitHub PR bot run.
Why the two-tier resolver matters
The honest answer to “which element did you click?” is the difference between a test suite you trust and one you argue with. Exact strategies are accepted as-is, because there is nothing to infer: if the button’s accessible name is Add to cart and the step says Add to cart, that is the button. Everything else (a loose text match, a partial name, a miss) goes to the model with the page’s actual elements in front of it, rather than being guessed at by a cascade of heuristics. The practical consequence: when a step fails, it fails with a description of what the page really showed. “No ‘Provision Worker’ button or link is visible The page shows a Users list with an ‘Invite user’ button and various user row controls.” That is a finding you can act on.Why a failure is attributed
Every failure carries a cause, decided where the failure was raised:
A report that suggests you check your selectors when the browser actually threw
is worse than no report. The attribution is set at the throw so that cannot
happen.