Automate your routine non-regression tests, without writing code.
Non-regression testing checks that what worked yesterday still works after today's change. It is the most repetitive testing there is, which is exactly why it should run itself. With Testorim each check is a sentence, not a script.
Join the waitlistHow to automate routine non-regression tests without code
- 1.
List the checks you repeat
Sign-in, checkout, the main form, search: the flows you click through before every release.
- 2.
Write each one as a sentence
Say what to do and what should be true at the end, as you would brief a tester.
- 3.
Run it once and read the result
Testorim plans the steps and runs them in a real browser. Keep the run when it did what you meant.
- 4.
Save it as a procedure
A saved procedure replays the same steps every time, without planning them again.
- 5.
Put it on a schedule or in CI
Run the set every weekday morning, on every pull request, or from your pipeline, and get told when one fails.
From a checklist to a suite that runs itself.
Regression automation without a test framework. The same five steps give you an automated smoke test on every deploy and a fuller non-regression suite every night.
- 01
Name the routine
Write down what someone checks by hand before a release. Five flows that matter beat fifty nobody reads: start with sign-in, the thing people pay for, and the form that brings in leads.
- 02
Describe, don't script
"Sign in as the demo user, add the first product to the cart and check the cart badge shows 1." Testorim turns that into steps, runs them in Chromium, and shows each step as it happens.
- 03
Keep the good run
Save a run you trust as a procedure. Its steps are fixed from then on, so Monday's check and Friday's check are the same check.
- 04
Let it run on its own
Schedules (every weekday at 09:00, every hour, your own cron), the testorim CLI in your CI pipeline, the REST API, or a GitHub pull request's preview link, so the checks sit in your DevOps pipeline like any other automated test. Failures reach Slack or email.
- 05
Only read the failures
A passing suite needs nothing from you. A failure arrives with the step, the evidence and whether the app or the test was at fault.
A morning check that used to be a person's first ten minutes.
Illustrative example, not a customer story. The app, the account and the wording are invented; the shape of the run is real.
The request
“Sign in as demo@example.com with the password from the test account, open Invoices, and check that the list shows at least one invoice and the New invoice button is enabled.”
The steps Testorim plans
- 1navigateOpen /login
- 2typeEmail field: demo@example.com
- 3typePassword field: (hidden)
- 4clickSign in button
- 5clickInvoices link
- 6assertInvoice rows: at least 1
- 7assertNew invoice button is enabled
When it passes, the report says
Passed. 7 of 7 steps passed. The account signed in, Invoices opened with invoices listed, and New invoice was enabled. Saved as a procedure and scheduled every weekday at 09:00.
When it fails, the report says
Failed at step 6. Invoices opened but the list was empty and the page read “Could not load invoices”. Every earlier step passed, so this points to the app, not the test. The team got the report in Slack before anyone opened the app.
A third result, needs review, means no step failed but something could not be confirmed, so a person should look before trusting it.
What it cannot do.
Web apps only
No native iOS or Android apps, and no desktop software.
Codes stop unattended runs
A scheduled or CI run cannot type a code from an email or SMS. Use a test account without a code step.
Public addresses
localhost and private network addresses are refused. Point it at a staging or preview address the internet can reach.
Intended changes need a new run
A saved procedure replays what was saved. When the flow changes on purpose, describe it again and save the new run.
Real side effects
A run signs up, orders and submits like a user. Use staging and stop before payment where you can.
Not a replacement for unit tests
It checks what a user can do in the browser. Logic deep in the code is caught faster by unit and integration tests.
Quick answers
What is non-regression testing?
Checking that what worked before a change still works after it. It is the same thing as regression testing; "non-regression" is the usual name in French and much of Europe (tests de non-régression). The checks are routine by nature: the same flows, run again after every change.
How can I automate routine non-regression tests without code?
Write each check as a plain-English sentence, run it once in Testorim and keep the run that did what you meant, save it as a procedure, then run the procedures on a schedule, from CI or on each pull request. No selectors or scripts are written at any point.
Is non-regression testing the same as smoke testing?
Overlapping, not the same. A smoke test is a short, shallow set of checks that the app is up and its main paths open. A non-regression suite goes deeper into the flows a change could break. Many teams run the smoke set on every deploy and the fuller suite nightly or before a release; both can be saved procedures on different schedules.
What is the difference between retesting and non-regression testing?
Retesting runs the one check that failed, after the fix, to confirm the fix worked. Non-regression testing runs the other checks too, to confirm the fix broke nothing else. With saved procedures both are a re-run: the failed procedure first, then the rest of the set.
Is Testorim a low-code automation tool?
It is no-code, which is stricter: you never write code or a selector, only the sentence. Teams comparing low-code automation tools use it the same way, and a saved run exports as Playwright TypeScript if you later want the test in code.
Do the saved tests break when the page changes?
Less often than recorded ones. Each step finds its element by role, label, placeholder and visible text rather than a recorded selector or position, so a moved button or a new class name is still found by its label. When the flow itself changes, describe it again and save the new run.
Does every replay call the AI again?
Replays do not re-plan: they run the saved steps. A model is still used to write the report, and to confirm an element when the page offers no exact match for a step.
What does a failed run tell me?
Which step failed and why, with a video, screenshots, a Playwright trace and a written report. The report says whether the app did something wrong or the test asked for something the page does not have, so you know who should look at it.
Keep building the suite.
No-code regression testing
The release-day version: which flows to save and how they run before each deploy.
Record and replay testing
Why recorded tests break, and what an autonomous run does instead.
Regression testing tools
How to choose a tool you will still trust six months in.
QA automation without coding
Move a whole manual QA checklist into browser runs.