Turn release anxiety into saved browser procedures.
Describe the flows that break releases: checkout, login, billing, onboarding. Save the good run. Replay it before the next deploy.
Join the waitlistCheckout
video + trace
Sign-in
screenshots
Billing upgrade
step 3 / 5
Onboarding
procedure
Same checks, after every change.
Regression testing re-runs the checks that passed before, to confirm a change did not break them. Non-regression testing is the same practice under the name much of Europe uses. Either way the work is the same flows, again and again, which is why it should not be done by hand.
With Testorim each check is written once as a sentence, run in a real browser, saved, and replayed before every release. How to automate non-regression tests without code.
A release checklist, already written as tests
Each line is a test you can paste in, run once and save. For the longer version, see the full pre-release QA checklist.
- 1.
Sign in
“Sign in as the QA account and check the dashboard shows the account's name.”
- 2.
Sign up
“Sign up with {{random.email}} and check the welcome screen appears.”
- 3.
The main flow
“Add the first product to the cart, go to checkout, and stop before paying.”
- 4.
The form that brings leads
“Fill in the contact form and check it says the message was sent.”
- 5.
Search
“Search for a product you know exists and check it is in the results.”
- 6.
Settings
“Change the display name, save, and check the header shows the new name.”
How to automate regression testing.
- 01
Pick the flows that must not break
Sign-in, checkout, billing changes, onboarding, the main form. A handful of flows that cost money or trust when they fail is a better start than a long list.
- 02
Describe each one once, in English
Write it like a brief to a tester and end with what should be true. An AI model plans the steps and a real Chromium browser runs them while you watch.
- 03
Save the run you trust
A good run becomes a procedure. Replays use the saved steps without calling the AI for planning, so every release gets the same check.
- 04
Run the set before each release
Trigger procedures from CI, the testorim CLI or the REST API, run them on a schedule, or point them at a GitHub pull request's preview link. Environments hold each address with its own headers and cookies.
- 05
Read what broke
Each run ends passed, failed or needs review, with a video, per-step screenshots, a Playwright trace and a report that says whether the app or the test was at fault.
A checkout check you replay every release.
Illustrative example, not a customer story. The shop, the product and the discount code are invented, and the wording below shows the shape of a run.
The request
“Add the first product on the shop page to the cart, go to checkout, apply the code SAVE10, and check that the order summary shows Discount applied. Stop before paying.”
The steps Testorim plans
- 1navigateOpen /shop
- 2clickThe first product's Add to cart button
- 3clickCart link
- 4clickCheckout button
- 5typeDiscount code field: SAVE10
- 6clickApply button
- 7assertThe order summary contains “Discount applied”
When it passes, the report says
Passed. 7 of 7 steps passed. The first product went into the cart, checkout opened, the code SAVE10 was accepted, and the order summary read Discount applied. The run stopped before payment, as asked.
When it fails, the report says
Failed at step 7. Apply was clicked and the order summary showed “This code is not valid” instead of Discount applied. The code field held SAVE10 and every earlier step passed, so this points to the app rather than the test: the app refused the code.
A third result, needs review, means no step failed but something could not be confirmed, so a person should look before trusting it.
Saved procedures vs a manual regression pass.
The older approach is a person clicking through a checklist before each release. It costs nothing to start and catches things no script would, but it gets skipped exactly when releases are rushed.
| Manual regression pass | Testorim | |
|---|---|---|
| Who does it | A person clicks through a checklist before each release. | Saved procedures run in a browser. A person reads the failures. |
| When it runs | When someone has time, often just before a release. | On a schedule, from CI, the CLI or the REST API, or on a pull request's preview link. |
| Consistency | Steps get skipped when a release is late. | The saved steps run the same way every time. |
| Evidence | Notes and screenshots someone remembered to take. | Video, per-step screenshots, a trace and a report for every run. |
| The unexpected | A person notices a broken layout nobody listed. | Checks what the procedure describes, plus an accessibility scan and console and network errors. |
When a manual pass is the better choice.
- A release that redesigns a flow, where a person should judge whether it still makes sense.
- A small app with rare releases, where a short click-through costs less than any tool.
- Checks outside a browser, such as a native mobile app, an email or a printed document.
- The first pass on a new feature, before anyone knows what the finished flow should be.
What it cannot do.
Saved steps stay as saved
A procedure replays what was saved. When a flow changes on purpose, such as a new step in checkout, describe it again and save the new run.
Codes in unattended runs
Scheduled and CI runs cannot answer a 2FA, email or SMS code. Give them a test account without a code step.
Public addresses only
localhost and private network addresses are refused, and so are previews that only exist inside your network.
Web apps only
No native iOS or Android apps, and no component tests.
Real side effects
A regression run places orders and creates accounts like a user would. Point it at staging and stop before payment where you can.
Not unit tests
It checks flows through the interface. Logic errors deep in the code are caught faster by unit and integration tests.
Quick answers
How do I stop manually testing my web app every time we ship a new feature?
Turn the repeated release checklist into saved browser procedures. Start with sign-in, sign-up, the product's core action, checkout or billing, and key forms. Run each check once in a real browser, save the run you trust, then replay those same procedures from CI, on a schedule, or against a pull-request preview before release. Keep manual QA for new or exploratory work that needs human judgment.
What should I regression-test first?
Start with revenue and access paths: sign-in, checkout, billing changes, onboarding, and important form submissions.
How does regression testing work?
You keep a set of checks that passed before, then run them again after every change to catch anything the change broke. Automated, each check is a saved browser test that replays the same steps before every release and reports only what failed.
Do saved procedures use AI every time?
No. Saved procedures replay the stored steps without calling the AI for planning, so each release runs the same check.
How do regression tests run in CI?
Trigger a saved procedure from your pipeline with the testorim CLI on npm or the REST API. The same saved steps can also run on a schedule or against a GitHub pull request's preview link.
What happens when the UI changes?
Steps find elements by role, label, placeholder and visible text rather than recorded positions, so a button that moves or gets a new class name can still be found by its label. When the flow itself changes, describe it again and save the new run.
Can this replace all regression testing?
No. It is strongest for browser-level product flows. Keep unit, integration, and code-owned E2E tests where they already work well. Saved procedures export as Playwright TypeScript if you want them in that suite.