Vera understands the journeys and rules your business depends on, continuously verifies them across your product, and shows your team when a change creates release risk — before it reaches customers.
No signup, no card. One AI-written test, run in real Chromium.
Requirements‑aware · Real execution · Multi‑actor workflows · Performance · Security signals · CI‑ready
“But how do you know an AI-written test actually tests anything?” — the answer ↓
See it in action
Six things most testing tools make you wire up by hand. In Vera they’re one sentence, one click, or one command.
Type one plain-English sentence. Vera reads your live page and writes real, passing steps — every selector proven, not guessed.
When a selector rots mid-run, Vera snapshots the DOM, finds the real one, retries, and records the fix. The run continues — and the result is reported as passed on heal, never folded into a clean pass.
The agent runs tests right next to localhost — no tunnels, no database access. Native mobile too, via Appium.
Sweep any page for accessibility, SEO, security headers, and Core Web Vitals — issues counted per page, ranked by severity.
Upload a CSV and each row runs the test with its own values — one authored flow becomes a whole matrix of real runs.
Import from the tools you already use, and export any test back to runnable code. Your suite is never trapped in Vera.
Why Vera
Every team wants coverage. Almost none can sustain it — because the tests themselves are code, and code rots.
Selectors, waits, fixtures, auth — a QA analyst can describe the flow but can’t code it, so tests never get written.
A renamed class or restructured DOM silently breaks suites. Maintenance quietly outgrows the value of the tests.
Once red means “probably nothing,” the suite is dead weight. People stop reading it — and stop trusting it.
Start with the business
Not with a blank test file. Hand it the requirements document you already have, and it proposes the rules your product must obey — each one carrying the page and clause it came from.
A BRD or RSD as .docx or .pdf — or an OpenAPI spec, a Postman collection, or your source. No new format to author.
→Each proposed rule keeps the document, section and snippet it was read from. You are reviewing a quote, not a summary.
→Nothing generates against a proposed rule. Approval is a human act, and it is the only door in.
→Tests are planned and scored against the rules you signed off — so “covered” means covered against your requirements, not against whatever the app happens to do.
It tells you what it did not read. Vera extracts requirements from structure it can actually see — acceptance criteria, numbered clauses, Gherkin, shall/must statements — and reports the lines it treated as prose rather than guessing at them. A document written as flowing narrative will yield few rules, and the import says so instead of quietly returning a short list.
A scan is refused, not guessed. A PDF with no text layer is images of text. Vera does not run OCR and will not pretend otherwise — it rejects the file and tells you to export a text-bearing one.
And a rule read from a document can contradict your running app — which a rule inferred from the code never can, because it was read out of the implementation and inherits its bugs. Why that distinction decides what a test can prove →
Risk & release confidence
Vera does not guess how critical something is. A person sets the factors, the band follows from them, and the band reaches everything linked to that rule — so before you approve it you can see what it will start gating.
Reasons recorded with it: blast-dominant, irreversible-at-ceiling. Not a number a model produced — a judgement somebody signed.
The rule: “a customer must not be able to request a refund on an order they do not own.” Approving P0 raises these three and any suite that gates on them.
You see the reach before you approve, not after. An approval that silently starts blocking releases is one nobody makes twice.
And Vera does not claim to watch your repository. It shows what a change to this rule would touch. Where it reports tests affected by a recorded change, an empty list means no change was recorded — which is not the same as nothing having changed, and Vera will not let the two read alike.
A band is only worth as much as the tests it reaches, which is why a test that cannot fail is not counted as covering anything →
Complete workflows
Model the customer, the support agent and the finance approver as named actors, each with their own project, role and environment. Vera runs the handoffs between them and carries what one stage learned into the next.
handoff · Customer published refundId = REF-4471 → Support and Finance both asserted against it
The handoff is the evidence. Every run records what each stage published, so “the reference the customer got is the one finance approved” is something you read off the report rather than something you hope held. A value marked sensitive is masked in that record and still real in memory for the next stage.
Actors can also run at the same time. Where the workflow genuinely has independent people, stages run concurrently and a dependent stage waits for all of them — and concurrency is opt-in per scenario, so a workflow written as a sequence never silently starts running two actors at once. The two races that would make it unsafe — two stages publishing the same variable, one actor in two concurrent stages — are refused when you save the scenario, not debugged at three in the morning.
Built for products where the work changes hands: marketplaces, approval workflows, and regulated or operational handoffs. If a fail is only visible to the third person in the chain, one-actor testing was never going to find it.
Where it fits
The same machinery pointed at three business shapes. These are modelling exercises you can copy rather than case studies — each names the actors, the handoff between them, and the one sentence a human has to approve before anything is generated from it.
The sentence in monospace is the actual unit of work. It goes in the project’s rule book, a person approves it, and the tests are generated from the approved sentence rather than from a model’s reading of your UI. That is the difference between a test that encodes what the product must do and one that encodes what the product currently does — the second kind passes forever, including on the day the behaviour was wrong.
None of these is a vertical edition, and there is nothing to switch on. They are the same actors, environments and rules the rest of this page describes, arranged the way that industry already works.
Critical-journey coverage
Not “how many tests do we have?” — that number goes up while the checkout stays unprotected. Vera maps the journeys your business depends on and tells you, per journey, whether anything is actually guarding it.
“Covered” does not mean “passing.” A journey is covered when the tests linked to it exist and have run — whether they passed is the health column, and whether they assert anything at all is a third question again. Finance approval above is covered and failing; that is not a contradiction, it is the point. One blended percentage would hide all three.
A journey with a deleted test reads partial, never quietly thinner: the broken link stays visible until somebody decides about it.
Vera can propose journeys by crawling your app — and they stay suggested until a person confirms them. An unconfirmed guess never counts as coverage, and never enters the denominator. How Vera proves a test tests something →
The hard question
A test that passes no matter what your app does is worse than no test — it reports green, and it counts as coverage. Four gates stand between a generated test and that word. The third is the one that matters.
Vera maps the live DOM first, so the model writes against selectors it has checked exist.
No interaction, no assertion, or a step missing its selector — caught before you see it.
Vera re-runs the test with its expectations flipped. Every control must fail. If it passes both ways, the assertions are inert — and Vera says so.
A rule counts as covered only once a test that proved it can fail has run against it.
Vera has a status that is worse than untested. It is tested by a test that proves nothing — and it is reported as a problem rather than folded into a percentage.
Who it’s for
Everything you need to stop shipping regressions, without writing or maintaining test code.
Org-grade controls on top of the same engine — so green means green and red means real.
Get started
Show Vera what your business depends on and start protecting it before the next release. Free plan, your own AI key, no credit card.