Testing your web app in plain English
How to describe a regression check the way you'd explain it to a teammate — and let an AI agent run it in a real browser.
Most test automation asks you to translate an intention — “make sure a new user can sign up” — into selectors, waits, and assertions. The intention is simple. The translation is where the hours go, and where tests rot the moment the UI shifts.
Plain-English testing flips that. You write the intention; an agent does the translation, live, against your actual app.
What a plain-English test looks like
Instead of a brittle script, you write the check the way you’d hand it to a new teammate:
Go to the app, create a project called Demo, and confirm it shows up in the project list.
That’s the whole test. When it runs, the agent opens a real browser, performs each step, and reports back what happened — with a screenshot as proof.
Why this holds up better
A selector-based test breaks when a class name changes. A plain-English test describes behavior, so it survives refactors that don’t change what the user experiences:
- No selectors to maintain. The agent finds the “create project” button the way a person would.
- Readable by anyone. Your PM can read the test suite and know exactly what’s covered.
- Graded, not just green/red. Every run comes back pass, fail, or blocked — “blocked” being the honest answer when something outside the test (a down dependency, a missing fixture) stopped it.
Where it fits
Plain-English testing isn’t a replacement for unit tests — those are fast and belong in CI. It’s for the end-to-end regression layer that’s traditionally the most expensive to write and the first to be abandoned: the multi-step flows that actually mirror how customers use your product.
Describe the flow once. Run it every release. Get a graded report with proof.
That’s the loop.