Finally, the correct way to test
Test automation you can read before you trust.
Correctest is a platform for teams who build web applications. Point it at your app and it explores it with an AI-driven browser, writes everything it learns into a Knowledge Base you can inspect and correct, checks your own user stories and business rules against what the app really does, finds the places your app accepts what it should refuse, and generates a plain Playwright test project you own and run in your CI. AI does the thinking during the scan. The tests it hands you never call AI.
For QA leads, test engineers and product teams who want automated tests without a black box, and for the manual testers who would rather spend their day on judgement than on typing invalid values into forms.
What it does
Six things, in the order they happen.
Correctest is not a test runner and not a managed testing service. It is a platform you drive yourself: you point it at your application and it works through it the way a careful new hire would, writing everything down as it goes. There is nothing to install, and the only thing you download is the test project at the end. During the design-partner phase we set your account up by hand rather than opening self-serve signup.
It maps your application.
Every page it can reach, classified by what it is (a login, a checkout, a settings page); every form, field and flow inventoried with working selectors; as a signed-out visitor or as any role you give it a login for. Pages that only exist after an interaction, and pages behind your login wall, included.
Discovery →It shows its homework, then stops.
For every field it prepares a valid value and a set of invalid ones, each with a confidence score and a written reason, and pauses. You add, edit or remove anything. Nothing is submitted to your app until you say so. Your edits never overwrite what it proposed; both are kept.
The review checkpoint →It finds defects before any test exists.
It submits the values, watches what your app does, and compares that with the rules you confirmed. A field that accepts a value you agreed was invalid becomes an application finding with a suggested severity, the kind of behaviour a defect is typically raised for, found before a single test was generated.
Findings →It reads your documents and checks them against your app.
User stories, Gherkin, Jira exports, business rules, data dictionaries, glossaries. It turns them into facts, corroborates them on upload, walks the journeys your stories describe, and tells you where document and app disagree, without ever deciding for you which one is right.
Documents & stories →It records everything as evidence.
Before-and-after screenshots of every submission, observation records with the app's own error text, a plain-English activity feed, a video reel of the scan indexed by page and flow, and a "verify" control on every fact. You can check its work instead of trusting it.
Evidence →It hands you a test suite you own.
A complete Playwright project: page objects, specs, fixtures, a CI workflow, a coverage report that says what was left out and why. Every assertion names the observation it came from. Zero AI calls at runtime, ever. Drop it into your repository and run it without us.
What you get →Why it exists
Tests you can't read are tests you can't trust.
Many AI test tools go straight from "we scanned your app" to "here are your tests", with little to review in between, and some patch failing tests at runtime without always showing you what changed. When an assertion is wrong, you find out in CI, or never. Correctest's difference is the layer in the middle: an inspectable, auditable Knowledge Base you can review and correct before tests are generated, so the AI's work is transparent, not a leap of faith.
- What did it learn about your app? Often invisible.
- Why does test 41 assert that? Often untraceable.
- Wrong assumption baked in? Regenerate and hope.
- Everything it learned is written down, in a structured knowledge base.
- Every test traces back to an observation with evidence.
- Wrong assumption? Correct the record before generation.
- Generated tests are deterministic Playwright: no AI, no vendor calls.
“Correctest learns your application; it never judges it.”
The rule behind everything on this site. Correctest records what your app does. It never decides what your app should do. When your form accepts a malformed email, the record says so, flagged for your attention, never silently "fixed". When your story and your app disagree, it asks which one is out of date. Drift detection, not opinion enforcement.
How it works
Four stages, and one checkpoint that matters.
Set up an application: its address, and optionally where its sign-in page lives. Add logins for the roles you care about, saved once and never shown again. Upload any documents you already have. Then:
Discover
A browser agent explores your app page by page, form by form, flow by flow, up to the breadth you set, as any role you give it a login for.
Review
The pipeline stops. You read the values it prepared and what it believes about your app, and correct anything it got wrong. Nothing is submitted until you continue.
Replay
It submits synthetic data through your forms and flows and records what actually happens, not what the docs say should happen. Every scan has a hard spend ceiling it cannot exceed.
Generate
From the corrected Knowledge Base it generates a complete Playwright project. You own it and never call us from it.
Who it's for
Three people on the same team, three different reasons.
A suite you would have been proud to write.
Page Object Model throughout, one spec per flow, fixtures, a CI workflow, every assertion traced to an observation. Change one page object when your UI changes and every spec adapts. Re-point the whole suite at staging with one environment variable.
Defects and stale requirements, before release.
Validation gaps in your app, and user stories that no longer match it, surfaced with evidence you can hand to a developer: what was submitted, what the app said, the screenshot, and your own document's sentence beside it.
The tedious part done; the judgement left to you.
Field-by-field probing with invalid values, the recording of what the app answered, the before-and-after screenshots: done, and written down. Criteria that genuinely cannot be automated, a back-office approval or an overnight job, are not silently skipped; the generated project ships a written manual-test procedure for each, so the human work is a deliverable too.
The proof
We ran it on our own application for one evening. Here is what happened.
One evening: two scans of the test application we build Correctest with, no edits, no retakes, every screenshot the product's own screen. It mapped the app, showed its homework, found eleven fields that accepted what they should have refused, caught a user story that had gone stale, and handed us a repository.
Why you can trust it
We point Correctest at Correctest.
Every screenshot on this site comes from the product scanning the application we build it with. Not a staged demo and not a mock-up: one real evening, in order, with the results left exactly as they came out. It found eleven fields in our app that accepted values they should have refused, and it told us one of our own user stories had gone stale. It also pointed at things worth improving in Correctest itself, and those shipped within two days. A tool that can't survive being pointed at its makers has no business being pointed at your application.
No badge wall. A ledger.
Our Trust Center lists what's true today, what's in build, and what we don't have yet, including the certifications we haven't earned. It names every vendor your data touches and sets out the operating agreement we ask of your organisation. If you're a security reviewer, start there.
Open the Trust Center →Built for the stack you actually have.
Modern component apps, where the controls hide inside web components. Embedded frames, tested into when they're yours and verified at the boundary when they're someone else's. Charts drawn onto a canvas, described and asserted rather than skipped. Salesforce, verified against a real developer org before we claimed anything about it.
What it handles →Live, and set up by hand.
The platform runs in production on managed cloud infrastructure. During the design-partner phase we onboard you personally rather than opening self-serve signup, so your first scan is configured with you, on your application, by the person who built it.
Request a pilot →Correctest is a young product, and we would rather you heard its limits from us than discovered them yourself. What isn't built yet is named on the roadmap, item by item, with what each one means for you.
Design-partner program
We're picking a few partners carefully. If your app deserves tests you can read, let's talk.
Every engagement is operated hands-on by the founder. You'll see the same screens you see on this site, on your own application, before you decide anything.
Where's the pricing page?
There isn't one yet, on purpose. We're in the design-partner phase: commercial pricing is being finalised with our design partners rather than invented in a vacuum. What we can say now: it's designed to cost a fraction of what one automation contractor costs you in a quarter, and it's discussed openly, with numbers, in the pilot conversation. Inside the product you see credits, never dollars, and every scan has a hard ceiling it cannot exceed.