What Vera is

A complete testing platform, operated in plain English.

Three ways to get a test — all no-code, all producing real browser runs with video, traces, screenshots, and results.

01 · Record

Click through your app

Vera captures each action in a live browser and derives a stable selector from a tiered priority ladder — data-testid first, CSS path last, generated classes filtered out.

data-testid → id → name → aria → role → …
02 · Generate

Write one sentence

The AI reads your live page, maps every interactive element, and writes complete scenarios using selectors that genuinely exist — then runs them to prove they pass. A value guard rejects tests that pass while doing nothing.

“Check the cart, apply a coupon, and check out.”
03 · Repair itself

Let it keep up with your app

Broken selectors heal mid-run. Failing tests enter an auto-repair loop — heal, suggest a fix, diagnose — and a fix is only accepted once the test actually goes green. Every repair is recorded for your review.

heal → suggest-fix → diagnose · green-gated

The full capability index

Every detail, in the box.

No “contact us to unlock” asterisks. This is the whole platform, itemized — small details included, because the small details are where suites die.

Know what must work

  • An approved rule book — the business rules your product must obey, each one human-approved before anything generates against it.
  • Rules from your API contract — an OpenAPI spec or Postman collection read deterministically into proposed rules. No model involved.
  • Critical-journey coverage — which business outcomes are protected, which are gaps, AI-proposed and human-confirmed.
  • Edge cases as data — one parameterized test plus rows derived from a rule, not N tests a model wrote.
  • Negative controls — a test that cannot fail is marked insensitive and does not count as coverage.
  • Role matrices — per-role expectations where “denied” needs an observed refusal, never an inferred one.
  • Cross-project chains — sequence tests from different projects into one run, threading captured variables between them.

Build tests without code

  • 27 step types — navigate, click, fill, select, hover, waits, asserts, API requests, extract-to-variable, native tap & swipe…
  • Data-driven datasets — upload a CSV; each row runs the test with its values as {{column}} variables.
  • Real control flow — if / else and loops, with element, URL & variable conditions.
  • Human-grade asserts — toast, modal & validation-error assertions that need no selector.
  • 6 selector strategies — test-id, role, label, placeholder, text, CSS.
  • Reusable flows — share step sequences across tests, inlined at run time.
  • {{variables}} — per-project and per-environment, injected into any field.
  • Live recorder — tiered selector ladder, streamed to your browser as you click.
  • One-click clone — fork a test and tweak the copy.

Let AI write the first draft

  • One-sentence suites — the AI reads the live page and proves each scenario by running it.
  • Journey crawl — multi-page agentic exploration, bounded by hard caps.
  • Value guard — scenarios that “pass while doing nothing” get rejected.
  • Self-healing selectors — DOM snapshot → corrected selector → retried → recorded.
  • Auto-repair loop — heal, suggest-fix, diagnose — accepted only when the test goes green.
  • Bug vs. drift diagnosis — reads your source read-only and classifies the failure.
  • AI design review — a vision model flags overlap, contrast & cut-off text in screenshots.
  • Auto-configure — proposes base URL, auth & seed commands from your repo; you approve.
  • Bring your own key — Anthropic, OpenAI, Google, or a local CLI.
  • MCP server — drive Vera from Claude or any MCP client.

Run it for real

  • 3 real engines — Chromium, Firefox, WebKit. No emulated DOM.
  • Real Chrome mode — headed system Chrome to get past bot detection.
  • 17 device profiles — iPhones, Galaxies, Pixels, iPads, desktops.
  • Multi-viewport runs — one test across desktop, tablet & mobile, each with its own baselines.
  • Parallel batches — suites with tunable concurrency, capped by a process-wide browser pool.
  • Retries & flake scores — passes-on-retry get flagged; every test carries a 0–100 flake score.
  • Quarantine — flaky tests keep running but stop blocking the suite.
  • Live progress — step-by-step streaming, even from queued background workers.
  • Local agent — npx vera-agent runs tests on your own machine, next to localhost. No tunnels, no DB access; results stream back to the dashboard.
  • Selenium / WebDriver engine — point any test at your own Selenium server or grid.
  • Native mobile — .apk/.ipa on your emulator, simulator, or device-cloud account (BrowserStack, LambdaTest) via the agent + Appium.
  • Suite matrix — expand one suite across devices × browsers, per-cell results in one run.
  • Watch mode — vera-agent watch --affected maps every save to the tests it puts at risk and runs exactly those, on your machine.

Prove it actually tested something

  • Video of every run — watch exactly what the browser did.
  • Playwright traces — kept on failure, optional on pass.
  • Failure screenshots — captured at the failing step.
  • Visual regression — pixel diffs against baselines, with approve / reject review.
  • Accessibility audits — axe checks with a severity gate you choose.
  • Site audit sweeps — crawl your site for a11y, SEO, security headers & Core Web Vitals, per page.
  • HAR of failed runs — a redacted network archive you can download — and re-import as API tests.
  • JUnit XML export — per run or suite, for any CI dashboard.
  • Public report links — tokenized, read-only, rate-limited, revocable.

Keep it working as the app moves

  • Cron schedules — with run-now and a next-run preview.
  • Environments — preview / staging / production, each with its own URL, variables & auth.
  • Setup actions — seed data before a run via allow-listed commands or HTTP calls.
  • Captured login sessions — log in once via API, reuse the session everywhere; per-role identities.
  • Coverage map — critical journeys vs. actual coverage and health, AI-proposed, human-confirmed.
  • ROI analytics — trends, flakiest tests, minutes saved.
  • Failure clusters — recurring breakages grouped by signature across runs, not scattered as noise.
  • Dynamic suites — membership by tag, recently-failed, or flaky — resolved fresh at run time.
  • Retention & cleanup — artifact storage that doesn’t grow forever.
  • Onboarding wizard — a seeded workspace in minutes.

Ship it with your team

  • Org workspaces — multi-tenant, everything scoped to your org.
  • Custom RBAC roles — permission-level control, not just admin / member.
  • Invitations & members UI — bring the whole team in.
  • Audit log — an append-only ledger of every mutating action.
  • Notifications hub — per-event rules to Slack, email & HMAC-signed webhooks, with a delivery log.
  • Issue push — send any Vera issue to GitHub, Jira, or Linear with back-links.
  • GitHub App — import repos, source-aware discovery, autosync proposals on merge.
  • vera-run Action — gate PRs on real failures; flaky counts as a warning.
  • CI API — bearer-token REST to trigger, poll, and wait on runs.

Performance

A flow can be functionally correct and still fail under real demand.

Every other test on this page asks whether your app does the right thing. None of them asks whether it still does it when four hundred people arrive at once. Those are two different questions, and Vera answers them separately — because an app can have an excellent LCP and fall over at fifty concurrent users, and a single score averaging the two would have told you neither.

One user, in a browser

LCPgood ≤ 2.5 s
CLSgood ≤ 0.1
TTFBgood ≤ 800 ms

Vera opens each page in a real browser and records these three Core Web Vitals per URL, then trends them across sweeps so a regression reads as a line that moved. The marks are Google’s published thresholds — a public standard rather than numbers Vera invented — and each is a default you can raise, lower, or switch off per project.

Many users, at the socket

p95 latencypass
error ratepass
p99 latencynot reported

A load profile ramps to your peak concurrency and holds it, measured at the socket — no browser, no render, nothing but the server answering. Each threshold you set comes back on its own as pass, fail, or unmeasured.

The two panels are never merged. LCP is how fast a page draws for one person. p95 is how fast your server answers while hundreds of people hit it at once. Different units, different conditions — average them into a single “performance score” and you get a number that means nothing. So Vera reports them apart, and a quick-loading page sitting in front of a server that buckles at peak shows up as exactly that, instead of settling into a reassuring B+.

A number Vera does not have, it leaves blank. The p99 row above says not reported because the load engine returns p95 and no p99 — so Vera prints nothing there rather than a 0, which would read as an instant response. The same rule runs through the whole product: a gap in a trend line stays a gap instead of becoming a zero, and a run that finished no requests at all comes back as an error — never a pass. “No threshold was breached” and “your app held up” are not the same sentence, and only one of them is true when nothing was measured.

Load runs and security scans are metered per month and included from Team upward. See the plan limits →

Get started

Your next critical regression should be found by Vera — not by a customer.

Show Vera what your business depends on and start protecting it before the next release. Free plan, your own AI key, no credit card.