CorrectestThe correct way to test Request a pilot

The proof

Rather than describe it, here's one evening.

We ran Correctest against the test application we build it with: one evening, two scans, no edits, no retakes. Everything below happened in the order shown, and every screenshot is the product's own screen from that evening.

0pages mapped
0flows replayed
0observations recorded
0validation gaps found
0tests generated
0 minfrom first crawl to finished scan

Screenshots are of Correctest scanning its own test application on a development stack. Only our account email and the host name were replaced; nothing the product reported was altered. Times are local, and run in sequence through a single evening.

5:18 PM01 · Documents

First, we gave it what we already knew.

Fifteen documents, straight from the folder: user stories in Markdown, Gherkin and a Jira-style CSV export; business rules as a PDF; a glossary; an API spec; a data dictionary. Each became facts the scan could later check. Fourteen were read into facts before anything touched the application.

Document page for account-registration.md: 18 facts read from this document, 15 new, 3 corroborated existing knowledge; then the first extracted facts, marked Extracted, Corroborated and New
account-registration.md, seconds after upload. Eighteen facts read; three of them already known from the glossary uploaded minutes earlier, and marked corroborated. Nothing has touched the app yet.
5:39 PM02 · Discovery

Then we pointed it at the app.

No login, no sitemap, no hints. Discovery narrates what it maps as it maps it: the index page, classified as a navigation hub with 121 interactive elements; then page after page, until 27 pages and 17 flows were in the knowledge base.

Activity feed: Started scanning; Exploring the application to map its pages and flows; Mapped the index as a navigation-hub page with 121 interactive elements
The activity feed, two minutes in.
Page detail for the registration form: 65 interactive elements extracted from this page, listed by name and type, plus 56 elements repeated across the app
One of the 27, the registration form. 65 interactive elements, each typed; the 56 that repeat across the app (header, navigation, footer) folded away. Every page gets one of these.
5:59 PM03 · Review

It stopped, and showed its homework.

Before submitting a single form it paused for review: 47 fields, 47 valid values and 113 invalid ones it had prepared, each with a confidence score and a written reason. Three values it wasn't sure about, and said so. You can edit, remove or add any of them. Nothing runs until you say so.

Review stage: the Username field with one valid value and two invalid values, each with a confidence score, a written reason, and Edit and Remove controls
One field on the review screen, captured on a paused scan of the same app. A valid value, two invalid ones, the rule each is meant to break, and the reasoning, in plain English.
6:00 PM04 · Replay

It submitted, and wrote down what the app said.

Seventeen flows, sixty-three observations. Each record holds what was submitted, what the app answered, verbatim, and how sure Correctest is. The judgement stays neutral: it records; you decide.

An observation record: server validation error, incorrect_password, the plain-English summary of what the app did, 95 percent confidence, seen 3 times, and a Judgement panel explaining that the record stays neutral
One observation record. A wrong password, rejected; 95 % confidence; seen three times; and a judgement panel that says, in the product's words, "the record here stays neutral."
“Correctest learns your application; it never judges it.”If your form accepts a malformed email, the record says so, flagged for your attention, not silently "fixed". You decide what's a bug and what's a feature.
6:19 PM05 · Findings

It found eleven things our app accepted that it shouldn't have.

A postcode field took NOTAPOSTCODE!. A terms checkbox took no. An email field took nothing at all. None of these become tests that would quietly pass; each is held out as a finding until you decide what it means.

11 validation gaps found in your app: your app accepted these invalid values with no rejection. Basic radio on the register page accepted premium, which should violate allowed_values; the I agree to the terms checkbox accepted no. Each finding offers Accept as intended behaviour or Dismiss.
The results screen. In the product's words: "This is a finding about your application's validation — not about Correctest's prediction."
Needs attention: Application findings, 18 in this scan, and the first finding: potential defect, suggested severity High, critical flow; the application accepted an empty value for Email on the confirm-submit page
Blind spots are listed, not averaged away. Eighteen application findings, each with a suggested severity you can overrule.

It also found our own story disagreeing with our own app. Three times.

The registration story from 5:18 PM says a mismatched password confirmation, an under-age visitor and a reserved username are each rejected. The app accepted all three registrations. Correctest put document and app side by side and asked which one is wrong.

Journey divergence AC4. Your document says: the application should keep the visitor in the registration flow and display a validation error when the password confirmation does not match. What the app did: the application accepted the registration and displayed Account created successfully with no validation errors. Buttons: This document is stale, This is an app defect.
Document versus app, one decision at a time. "This document is stale" or "This is an app defect". Correctest never picks for you.
6:32 PM06 · Repository

It handed us a repository.

58 tests across 12 flows, as a plain Playwright project: page objects, specs, fixtures, a CI workflow. Every test names the observation it is grounded in. Five flows were skipped, and the coverage report says why, including a password reset it refused to drive for real.

Your tests are ready: a complete Playwright project, generated from your Knowledge Base, yours to own and run. Download project. 58 tests, 12 flows covered, 5 flows skipped.
One click, one repository.
Coverage report: 58 tests generated, 12 flows covered, 5 flows skipped, 0 flows not generated; the password-reset-request flow is marked skipped with the reason that Correctest does not drive password resets for real
What was left out, and why. "A deliberate boundary of the scan, not an error."
// tests/flows/autocomplete-preferences-form.spec.ts — first test of two, as generated
import { test, expect } from "@playwright/test";
import { resolveCredentials, resolveFixedTestData, recordCreatedTestData } from "../shared/fixtures";
import { TestbedAutocompletePage } from "../pages/TestbedAutocompletePage";
import data from "../pages/TestbedAutocompletePage.data.json" with { type: "json" };

test.describe("autocomplete-preferences-form", () => {
  /**
   * Asserts the happy path: valid city + postcode saves location
   * preferences and navigates to the submission confirmation page with
   * a "Location preferences saved." banner.
   * Grounded in observation: 52f4f5ce-7952-432a-8efa-1deea36387cc
   * (confidence 0.95).
   */
  test("autocomplete preferences success — valid city and postcode save preferences", async ({ page }) => {
    const autocomplete = new TestbedAutocompletePage(page);
    const preferredCity = resolveCredentials(data.valid.preferredCity);
    const postcode = resolveCredentials(data.valid.postcode);
    await autocomplete.goto();
    await autocomplete.fillPreferredCity(preferredCity);
    await autocomplete.fillPostcode(postcode);
    await autocomplete.clickSubmit();
    await expect(page).toHaveURL(/\/testbed\/submit\/autocomplete/);
    await expect(page.locator('div.banner-success')).toBeVisible();
    …
  });
});
A real spec, verbatim. The imports above are the whole dependency list: no SDK of ours, no API key, no model call. It runs whether or not we exist.
testbed/80 files · 58 tests · from scan fc38ce21 package.jsondeps pinned playwright.config.ts3 browsers + retries .env.examplecredentials as env vars, none baked in README.mdwritten for your app coverage.matrix.jsonwhat was covered, and why not .github/workflows/tests.ymlCI workflow tests/auth.setup.tssigns in once tests/flows/12 specs, one per flow tests/pages/page objects + data tests/shared/fixtures, helpers
The project, as downloaded. Page Object Model throughout; selectors live in one place.

This scan explored as a signed-out visitor, so the project it produced carries no sign-in step at all: a suite authenticates only when the scan that produced it authenticated, and it says so rather than filling a login form with sample values.

6:56 PM07 · The question

Then we asked it to follow our stories on their own. And it caught us out.

A second scan, signed in as a Customer, walking the acceptance criteria in the documents from 5:18 PM. One story file was out of date: it fills a "full name" field the registration page no longer has. Correctest didn't force the walk through, and it didn't mark the story failed. It stopped, said what it couldn't find, and asked.

Conformance report header: Conformant 2, Divergence needs your decision 4, Story references something not on the app 3
The conformance report. "Correctest reports what it observed — it never decides for you which side is right."
Story card registration-is-rejected-when-the-passwords-do-not-match, verdict: Story references something not on the app. Your document expected: I see a validation error that the passwords must match. The app did: not observed. Your story references full name field, which the scan didn't find on the app. Is your story out of date, or is the app missing it? Where the walk stopped. Three choices: My story is stale, The app is missing it, Decide later
The moment from the top of this page, as it appeared. Between the question and the choices the card shows a screenshot of where the walk stopped, omitted here. Until you choose, that story's tests are held back: only conformant stories, stories you have accepted as stale, and defects you have resolved go on to generation.

That was our application. The interesting question is what it would find in yours.

What it handles →

One evening, two scans, no edits and no retakes. Eleven fields that accepted what they should have refused, a user story that had quietly gone out of date, and a Playwright suite at the end of it. Your application is not our test application, and the findings will not be the same ones. That is rather the point: the scan reports what your app does, and hands you the decisions.