Recording a flow
A tool watches you click through the app once and saves every click and keystroke, each tied to a selector for the element it hit.
Recorded tests break when the page changes shape. Testorim starts with what the user should accomplish, then resolves the current UI by role, label, text, placeholder, and healing.
Join the waitlistPlayback broke
click #checkout-btn
timeout: selector not found
layout shifted after redesign
Testorim resolved
“Click the checkout button”
role=button · name=/checkout/i
label fallback skipped
visible clickable ancestor found
Element resolved after UI text changed.
screenshot · trace · report saved
A tool watches you click through the app once and saves every click and keystroke, each tied to a selector for the element it hit.
The tool performs the saved clicks again. When a selector no longer matches, because a class was renamed or a button moved, the replay fails even though the app works.
With Testorim nothing is recorded: you write what should happen, the steps are planned from it, and each element is found again by its label and text on every run.
Write what the user does and what should be true at the end. There is no extension to install and no session to record.
Each step names its target the way a person would: the Add to cart button, the Email field. Nothing is tied to a coordinate or a generated selector.
By role, label, placeholder and visible text, in a real Chromium browser. When that matches more than one element, a model reads the live page and picks the one the step means.
A run ends passed, failed or needs review. The report says whether the app or the test was at fault, with a video, screenshots, a Playwright trace and console and network errors.
Save a run as a procedure to replay without calling the AI for planning, on a schedule or from CI, or export it as Playwright TypeScript.
Illustrative example, not a customer story. The shop and its pages are invented. Suppose a redesign gave the Add to cart button a new id and moved it into a side panel: a recording that clicked the old selector would stop at element not found. The step below names the button by its label, so it is found wherever the label is.
The request
“Search for blue mug, open the first result, add it to the cart, and check that the cart shows 1 item.”
The steps Testorim plans
When it passes, the report says
Passed. 6 of 6 steps passed. The search returned results, the first one opened, Add to cart was found in its new place and clicked, and the cart read 1.
When it fails, the report says
Failed at step 6. Add to cart was found and clicked, but the cart still read 0. The button responded and every earlier step passed, so this points to the app rather than the test: the item was not added.
A third result, needs review, means no step failed but something could not be confirmed, so a person should look before trusting it.
A recorder watches you use the app and saves what you did so it can repeat it. That is quick to start with, and for some jobs it is still the right tool.
| Recorder | Testorim | |
|---|---|---|
| Making a test | Click through the flow once while the recorder captures each action. | Describe the flow in a sentence; a model plans the steps. |
| What a step points at | A selector, position or page structure captured at recording time. | A role, label, placeholder or visible text, found again on every run. |
| When the page changes | A renamed id or a moved element can break the step even when users notice nothing. | A control with the same label is still found. A changed flow needs describing again. |
| Precision | Replays exactly what you did, including where you clicked. | Acts on what the step names. A vague step gets a vague result. |
| Cost and place | Playwright's codegen, Selenium IDE and the Chrome DevTools Recorder are free and run on your own machine. | $19, $79 or $199 a month, hosted, against a public address. |
You cannot click through a flow to create a test. Every test starts as a description.
An icon button with no label or text is harder to name in a sentence. A model can often pick it from the live page, but a label on the control is the reliable fix.
localhost and private network addresses are refused, so a recorder is still the tool for a site that only runs on your machine.
No native iOS or Android apps, and no component tests.
A live run can pause and ask you for a 2FA, email or SMS code. Scheduled and CI runs cannot.
No. Testorim is intent-first. You describe the behavior, and the system plans and executes browser steps. There is no recording mode.
Recorded flows often depend on exact selectors, timing, or layout structure. Normal UI changes can break them even when the user experience still works.
Its steps are not tied to a recorded selector in the first place. Elements are found by role, label, placeholder and text on every run, and when that is ambiguous a model looks at the live page to pick the element. If the flow itself changes, you describe it again.
No. Testorim does not import recordings or scripts. The steps in a recording are a good checklist for the sentence you write instead.
Yes. A saved procedure exports as Playwright TypeScript, so a flow described in English can move into a code suite later.
Starter is $19, Pro $79 and Team $199 a month, each after a 3-day trial that needs a card. Sign-up is currently by waitlist.
What recording is, why it breaks, and the autonomous alternative.
See how AI plans, executes, heals, and reports on browser runs.
Turn critical release checks into saved browser procedures.
The same trade without drivers, grids or XPath to keep alive.
What to look for when the goal is catching breakage every release.