Sign in Start testing
Softsurance/Frontend testingRelease 1

Every page, opened and checked.

Softsurance drives a real Chromium browser through Playwright inside the domains you authorise, and records what each page actually did — what loaded, what was visible, and what errored.

Start testing Read the docs

At a glance

EnginePlaywright · Chromium
LocatorsRole, label, text, test-id
WaitsDeterministic, no sleeps
RetriesBounded and recorded

The first release is built around this module: discovery, proposed tests, approval, execution, evidence and scheduling all work end to end for browser tests.

T-04 · Checkout CTAFailed
staging.demo-shop.test/cart
title ✓
button “Checkout” · not found
assert getByRole('button', { name: 'Checkout' }).toBeVisible() ✕ not visible within 5000 ms network GET /api/cart/summary → 500 console 0 errors · screenshot saved

01 / Capabilities

What it checks12 items

What it checks.

Everything a run checks, and the evidence it keeps when something fails.

  • Page load and HTTP statusRelease 1
  • Title and URL assertionsRelease 1
  • Visible, enabled and text checksRelease 1
  • Same-origin link discoveryRelease 1
  • Form and field inspectionRelease 1
  • Console error captureRelease 1
  • Failed network requestsRelease 1
  • Screenshot per stepRelease 1
  • Clicking and filling approved controlsRelease 1
  • Authenticated flows with a test accountPreview
  • Visual change detectionRoadmap
  • Cross-browser runsRoadmap

02 / How it works

Step by step5 steps

  1. Add the URL

    Enter a staging or production URL, confirm you’re authorised to test it, and list the domains that are in scope.

  2. Discover

    A browser opens the homepage and follows same-origin links within depth and page limits. It records titles, forms, buttons, console errors and failed requests — without submitting anything.

  3. Review proposals

    Discovery becomes a list of proposed tests: page loads, titles, navigation, key elements, error-free pages. Edit, approve, reject or exclude each one.

  4. Run and read

    Approved tests run in an isolated worker. Each step stores its assertion result, screenshot, console output and failed requests.

  5. Schedule

    Put the suite on a cadence from every 15 minutes to weekly. Every run, skip and retry is recorded.

03 / Guardrails

Enforced by the backendNot optional

The limits come first.

These rules are enforced by the execution backend. The interface can’t switch them off, and neither can an AI.

G-01

Scope on every request

Navigations, redirects and sub-resources are checked against your authorised domains and blocked if they fall outside.

G-02

No side effects in discovery

Discovery never submits forms, creates accounts, sends messages or makes purchases.

G-03

Timeouts everywhere

Each step, each test and each execution has a hard limit, so a hung page can’t hold a worker.

G-04

Bounded evidence

Screenshots and logs are size-limited, retained per plan, and readable only by your organisation.

04 / Questions

Frontend testing4 entries
Q.01Does discovery click buttons or submit forms?

It doesn’t submit forms or trigger actions. It reads pages and follows ordinary same-origin links within the limits you set.

Q.02Which selectors do generated tests use?

Accessible locators first — role and label — then visible text, then test IDs. Fragile CSS paths are a last resort.

Q.03What does “failed” mean versus “error”?

Failed means the page loaded but an assertion didn’t hold. Error means our infrastructure failed — a crashed browser or an unavailable service. They’re never mixed up.

Q.04Can I test pages behind a login?

With a dedicated test account stored as an encrypted credential. This is in preview; we never ask for anyone’s personal password.

Start

Your first runStaging URL required

Add a staging URL. Read your first real result today.

Start testing Read the docs