1. What is Testver Web?

Testver Web lets you test websites and web apps by driving a real browser — clicking, typing, and navigating exactly like a user — and checking that your app behaves correctly. It works with the test framework your team already uses (Playwright, Cypress, Selenium, and many more) and runs on your machine or on a cloud browser grid.

You can use it three ways, and mix them freely:

· AI Assistant — chat with an AI that drives the browser for you and writes the test.

· AI Record — click through your site in a browser; Testver records each step and generates a test from it.

· Run your own tests — run your existing test project (any supported framework) with one click, across browsers, and see results.

In one sentence:  Point Testver at your app and a framework, and it runs/records/automates your web tests across browsers — local or cloud — with live progress and parsed results.

1.1  Who this guide is for

Anyone who wants to test a website with Testver — whether or not you've used Playwright/Selenium before. Section 2 covers the few concepts you need. Unfamiliar term? See the Glossary (Section 13).

2. Core concepts (read this first)

3. What Testver Web supports

3.1  Browsers

·  Chrome / Chromium

·  Firefox

·  Safari / WebKit

·  Microsoft Edge

Which browsers you can use depends on your framework (e.g. Playwright bundles Chromium/Firefox/WebKit; Cypress uses installed browsers). Cloud grids add many more OS + browser-version combinations.

3.2  Where tests run

3.3  Frameworks supported

Testver runs your existing project. Supported web frameworks:

Testver doesn't replace your framework.  It detects what you already use and drives it for you — discovering tests, building the run command, capturing results, and adding AI + recording on top.

3.4  Tools you'll need

4. Features at a glance

5. One-time setup

Most web projects need almost no setup — Testver auto-detects your framework and the command to run it.

5.1  Local runs

1. Make sure your framework is installed in the project (e.g. Playwright, Cypress) and its browsers are available.

2.  Set your workspace mode to Web (or Both) so the web surfaces show.

3.  Open the Runner — Testver shows your detected framework and is ready to run on “Local (this machine)”.

5.2  Connect a cloud grid (optional)

4.  Create an account with BrowserStack, Sauce Labs, or LambdaTest and copy your username + access key.

5.  Open the Connectors screen and add the provider credentials.

6.  The provider now appears as a run target in the Runner — pick it to run on the cloud grid.

5.3  Run Commands (usually automatic)

Testver auto-detects the exact command for your framework (e.g. npx playwright test). You normally don't touch this. If your project runs tests in a non-standard way (a custom config, an npm script, special flags), you can customize the single-test / file / full-run commands in Settings → Run Commands. There's a dedicated guide for that — “Testver — Run Commands.”

6. The building blocks (how a web run is assembled)

Every web run comes down to a few choices plus what Testver does automatically.

6.1  Framework

Auto-detected from your project (the dependencies + config files). It decides the run command and how results are parsed. You can override the command in Settings if needed.

6.2  Where to run

Pick “Local (this machine)” to use your installed browsers, or a cloud provider to run across the grid.

6.3  What Testver does automatically

·  discovers your tests and builds the correct run command for your framework.

·  injects a structured reporter so it can parse per-test results.

·  for cloud runs, wires up the provider so the same tests run on the grid.

·  streams live progress and captures screenshots + results.

7. Ways to use Web (step by step)

Testver shows web surfaces when your workspace mode is Web (or Both). Here are the five entry points.

7.1  Run your own test suite — the Runner

7.   Open the Runner ( /runner ).

8.  Choose where to run: “Local (this machine)” or a cloud provider.

9.  Click Run.

10.  Watch tests stream pass/fail live as they execute.

11.  When it finishes, open Results for per-test outcomes, durations, errors, and screenshots.

7.2  Run one test — the Test Explorer

12.  Open the Test Explorer ( /tests ). It lists every test discovered in your project, grouped by file/suite.

13.  Find your test and click Run (it uses the single-test run command for your framework).

14.  View its source, steps, and result inline.

7.3  Let AI drive — AI Assistant (web mode)

15.  Open the AI Assistant ( /ai ) and set the mode to Web.

16.  Type what you want, e.g. “Go to the login page, sign in as a standard user, and verify the dashboard heading.”

17.  The AI opens a browser, performs the steps on a live browser view, and can generate a reusable test.

7.4  Record by clicking — AI Record

18.  Start AI Record in Web mode and enter your app's URL.

19.  Click and type through your flow in the browser. Each action is captured.

20.  Add assertions/annotations where you want checks.

21.  Click Generate Test Code — Testver writes a clean, runnable test in your framework with stable locators.

22.  The full session is saved in your recording history to revisit or regenerate.

7.5  Schedule runs — Schedules

23.  Open Schedules, create one, choose the framework/target, and set the time (e.g. nightly).

24.  Testver runs them on schedule and stores the results.

8. Framework support in detail

Testver runs your unmodified project. Default run command and how results are captured per framework:

Single-test, file, and full-run commands are all customizable per project — see the Run Commands guide.

9. Run Commands (customizing how tests launch)

Most users never touch this — the auto-detected commands work out of the box. But if your project runs tests in a non-standard way, Settings → Run Commands lets you customize three commands:

·  Single Test — run one test by name.

·  Suite / File — run all tests in one file.

·  Full Run — run the entire suite.

Each supports placeholders like {test}, {file}, {posixFile}, {suite}, {line}, and {args}, and there's a “Suggest with AI” button that inspects your project and proposes the commands. Full details are in the dedicated “Testver — Run Commands” guide.

10. Features in detail

10.1  Live progress & screenshots

As a run executes, tests stream their pass/fail status live. Failure screenshots and other artifacts produced by your framework are collected and shown with the results. AI Assistant and AI Record additionally show a live browser view while they drive the page.

10.2  Results

After a run, Testver locates your framework's report and parses per-test outcomes — name, status, duration, error message + stack, browser, tags, and screenshots — into the Results view. Cross-browser runs are grouped so you can see how each browser fared.

10.3  Cross-browser

Run the same tests across Chrome, Firefox, Safari, and Edge — locally (where your framework supports it) or across far more browser + OS combinations on a cloud grid.

10.4  Self-healing locators

When the page shifts and a selector would otherwise break, Testver's healing engine can re-find the element and repair the locator, keeping tests green. Configure it in Settings → Self-Healing.

11. Limitations & things to know

·  Local browsers — which browsers run locally depends on what your framework supports/has installed (e.g. Safari/WebKit needs the right platform). Cloud grids remove this limit.

·  Custom setups — Testver auto-detects the common frameworks. A very non-standard setup may need a custom Run Command (Settings → Run Commands).

·  Prerequisites — cloud runs require valid provider credentials in Connectors; local runs require the framework + browsers installed.

·  Results — results depend on your framework producing its report; if a custom reporter suppresses it, Testver may fall back to reading console output.

12. Troubleshooting & FAQ

Q.  Testver picked the wrong framework / command.

Open Settings → Run Commands and set the correct single-test / file / full-run command (or use Suggest with AI). Your override is used everywhere Testver runs your tests.

Q.  No results after a run.

Make sure the run actually produced your framework's report. For odd setups, customize the Run Command so the reporter is enabled.

Q.  My test runs but I don't see the browser.

Many frameworks run headless by default. Run headed (your framework's flag) if you want to watch — or use AI Assistant / AI Record, which show a live browser view.

Q.  Does Testver change my test project?

No. It detects your framework, builds the run command, and reads your framework's native report. Customizations you make in Run Commands are stored per-project (in .testver/), not in your test files.

Q.  Can I run across multiple browsers at once?

Yes — locally where your framework supports it, and broadly on a cloud grid. Results group the outcomes per browser.

Q.  Do I have to use the cloud?

No. Local runs work fully. The cloud grid is optional, for broad browser/OS coverage.

13. Quick start (the 2-minute path)

25. Set your workspace mode to Web (or Both).

26. Open the Runner — confirm the detected framework.

27. Click Run on “Local (this machine)”.

28.  Watch tests stream live, then open Results. Done.

14. Glossary