Infrastructure
WebDriver binaries pinned to browser versions, and a grid to run anything in parallel. Testorim runs the browser for you, and a run is an API call or a button.
Selenium alternativeKeep the coverage.
Keep the coverage.
Drop the maintenance.
Selenium is a library for people who write automation code. Most of the checks a team actually needs never get written, because somebody has to own drivers, waits and selectors forever. Describe the flow in English instead and let the run resolve the page as it is today.
Join the waitlistSelenium suite, week 40
chromedriver 118 ≠ chrome 119
NoSuchElementException: //div[3]/button
flaky: implicit wait raised to 15s
Same check, described
“Sign in and confirm the dashboard loads”
resolved by label, not XPath
settled on the page’s own signals
video · trace · report saved
What a Selenium suite asks of you, and what replaces it.
Selectors
CSS and XPath that encode today's markup. Testorim resolves by role, label, text and placeholder, and falls back to AI grounding when the page has moved on.
Waits
Explicit waits tuned per flow, the usual cause of flake. The runner settles on the page's own loading signals and in-flight requests instead.
When Selenium is still the right answer.
It is free, it is mature, and it drives more browsers and devices than anything else. If you need Safari on real hardware, a language other than JavaScript, or automation that lives inside your own repository under your own review process, that is Selenium's ground and it should stay there.
The flows teams tend to move first
- Sign-up and sign-in. High value, changes often, and the selectors move with every redesign.
- Checkout and billing. Worth checking every release, rarely automated because the flow is long.
- The long tail nobody wrote. Password reset, invite acceptance, empty states, the settings screen someone broke last quarter.
Quick answers
Is Testorim a drop-in replacement for Selenium?
No, and it is worth being clear about that. Selenium is a browser-automation library for engineers, in many languages, across many browsers and devices. Testorim is a QA tool that takes a plain-English description and runs it in Chromium. If your team writes and maintains automation code by choice, Selenium is a reasonable thing to keep. If nobody on the team wants to own that code, Testorim covers the flows without it.
What actually goes away if we switch?
The maintenance surface. There are no WebDriver binaries to match to browser versions, no grid to run, no explicit waits to tune, and no CSS or XPath selectors to update when the markup changes. You describe what the user should be able to do, and the run resolves the page as it is on the day.
Do we lose our existing Selenium suite?
No. Nothing here deletes or converts your suite. Most teams keep Selenium where it already works and use Testorim for the flows that were never automated because the cost of writing and maintaining them was too high.
How does it handle waits and timing?
The runner settles after each action using the page's own loading signals, in-flight requests, and document state rather than a fixed sleep. Long-running work can be asserted against a completion state instead of a hardcoded timeout.
Can we still get code out of it?
Yes. A saved run can be exported as Playwright code, so a flow you described in English can be handed to engineers as a script if you later want it in your own repository.
Related
Keep reading.
Cypress alternative
Same question, different framework: what changes when tests stop being code.
Playwright alternative
Where an intent-first runner fits next to a modern automation library.
Record-and-playback alternative
Why recorded clicks break, and what to preserve instead.
Regression testing tools
What to look for when the goal is catching breakage every release.