Web automation testing is easy to start and hard to keep going. Writing the first login test takes an afternoon. Keeping two hundred tests green while the UI changes every sprint takes a whole team.
It usually goes wrong in the same four places. Tests take too long to write. Locators break when the UI changes. Failures are hard to read. And running across browsers means setting up and paying for yet another service.
This guide walks through a complete web automation workflow in Testver, from a first recorded test to a suite that runs on every commit, and shows where AI saves time at each step. It works the same whether your tests are written in Playwright, Selenium, Cypress or WebdriverIO.
Before you start
You need three things:
Testver running on your test project. Run testver serve in the project folder (new here? start with Meet Testver).
A web test project. Playwright, Selenium, Cypress, WebdriverIO, Cucumber, Robot Framework, pytest and more all work. No project yet? The AI Assistant can create a complete, well-structured framework from scratch using its built-in skills.
An AI connection. Testver cloud AI (the free Starter plan needs no card) or a local model through Ollama or LM Studio.
When the project opens, the Test Explorer lists every test Testver found, each with its latest result. That's your starting point.
Step 1: Record a test by clicking through your app
Open AI Record, type a Starting URL (your staging site or http://localhost:3000) and press Start Recording. A Chromium browser opens with a live view beside the recorder. Every click, field you fill and key you press becomes a numbered step with a screenshot thumbnail.
While you record, three controls do most of the work:
Assert. Click an element to check it instead of clicking it: that it's visible, or that its text matches. This is what turns a recording into a real test.
Custom step. Use it for the parts that aren't clicks in the app: sign in with your existing login helper, load test data, read a password-reset email and keep its link.
Pause. Click around without recording, for example to close a cookie banner you don't want in the test.
When you're done, press Stop, name the test (or choose an existing one to merge into), and press Generate. The AI analyzes your project first and proposes a plan. Once you confirm it, the AI writes the test in your framework and your style, reusing the page objects you already have, then runs the test and fixes it until it passes.
Tip: record one user journey per test. "Sign in and add a product to the cart" is a good test; "test the whole site" is not.
Step 2: Or describe the test in plain English
Some tests are faster to describe than to click through. Switch the AI Assistant to Web mode and ask:
Write a Playwright login test for /login with valid, invalid, and empty-field cases.
The assistant reads your project, opens a browser to check the real page, writes the test and runs it. A live preview shows the browser as it works, and you can step in and drive it yourself at any point. In Manual mode, the default, the assistant asks before it writes a file, runs a command or drives the browser.
For a bigger head start, the Explore & Automate skill takes a URL and your rules. It explores the application the way a user would, writes a test for every journey it finds, runs them until they pass, and files a matching test case for each, along with a list of real defects it ran into.
Step 3: Run it on any browser
Run a single test with one click from the Test Explorer, or a whole suite from the Test Suite or Runner. Next to Run on, pick where the browsers come from:
Your machine: the browsers already installed for your framework.
Testver Grid: cloud Chromium, Firefox and WebKit with no vendor account, no keys and no changes to your test code. Tests run in parallel across as many browsers as your plan allows.
BrowserStack, LambdaTest or Sauce Labs, if you already use one of them.
On Grid, your framework's own configuration decides the browser: a Playwright project picks Chromium, Firefox or WebKit, and Selenium or WebdriverIO keep the browser set in code. A live view streams each browser while the run is going.
Step 4: Read the results
Every run lands in Results with screenshots, video, traces and console output for each step, plus the full history of each test, so a flaky test is easy to spot. A failing step opens the exact line of code in Testver's built-in editor.
Step 5: When a test fails
Web tests fail for two very different reasons, and Testver handles each one differently.
The app changed and a locator broke. A renamed data-testid or a moved label is the most common cause of red builds. Auto-Heal reads the page the test actually saw and proposes a new locator in your framework's own style. It then re-runs every affected test to prove the fix works. Nothing is kept unless that run passes. Start in Suggest mode (Settings → General → Auto-Heal): verified fixes wait in Results for one-click Apply. Switch to Auto later to keep verified fixes automatically.
Something else went wrong. Failure analysis groups failures by root cause and explains each one in plain English. One click hands the fix to the AI Assistant, and another creates a defect, in Jira too if you use it.
Step 6: Make it run without you
A suite only protects you if it runs on its own:
Schedules run a daily smoke suite or a weekly regression on a timer, with pause, resume and run now.
CI/CD Pipelines gate your builds. Your pipeline makes one call, the tests run on your Testver server where the browsers are already set up, the build waits for the verdict, and the result is posted back to the commit:
npx @testver/testver trigger --mapping "pr-gate" --server https://testver.your-company.com --token $TESTVER_CI_TOKENThe exit code is 0 when tests pass, 1 when tests fail, and 2 when there's no verdict. Ready-made templates cover GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, Bitbucket and CircleCI.
Tips for web tests that stay reliable
Start with the journeys that matter most: sign-in, search, checkout. A small reliable suite beats a large flaky one.
Assert outcomes, not just clicks. Every recorded test should end with at least one Assert.
Reuse what you have. Use a custom step for your existing login helper so every test signs in the same way.
Record against a stable environment with known test data, such as staging rather than production.
Go cross-browser before a release. Run the suite on Firefox and WebKit on Testver Grid, not only Chromium.
Turn on Auto-Heal in Suggest mode and review its fixes in Results for the first few weeks.
Wrapping up
The whole loop takes minutes rather than days: record or describe a test, run it on any browser, read what happened, let Auto-Heal handle UI changes, and put the suite on a schedule or behind a CI gate. Your tests stay plain framework code in your own repository throughout.