For manual testers

Playwright execution, without writing Playwright

You write the test the way you would describe it to a colleague. It runs in a real browser, driven by Playwright, and the same words produce the same run every time.

We are not an alternative to Playwright. We run on it.

Playwright is the execution engine, and it is excellent at being one. What it does not do is read a plain-English step — that is the part this adds. If your team writes Playwright by hand and enjoys it, you do not need us.

You write the step. In English.

No selectors, no page objects, no waits, no test file. A line of plain English per step, in a spreadsheet or typed in.

The grammar recognises the step and compiles it to an action — it is not a model reading your intent.
A line it cannot place is refused and named. It never becomes a step that silently passes.
The same line compiles to the same action every time, which is why two runs of one suite are comparable.

Playwright runs it

A real Chromium session, driven by Playwright — the same engine an automation engineer would have written against by hand.

Real browser behaviour: actual navigation, actual clicks, actual form submission.
Elements are resolved against the Knowledge Base your exploration built, with the confidence that chose each one recorded.
A weak match is refused rather than clicked, so a green run is not a run that clicked the wrong thing.
No model is consulted during the run. Nothing about the verdict depends on a third-party service being up.

You get the evidence, not a log

What a manual tester would have attached to a ticket, produced by the run itself.

A screenshot per step and a video recording of the session.
Per-step pass or fail, and the element each step acted on.
Values read during the run, against the step that read them.
A Word report, so the result can leave the tool.

What you write, and what runs

Go to https://shop.example.com/cart

a navigation, with the page settled before the next step

Enter '2' into 'Quantity'

the field found by its label, then filled

Click 'Update basket'

the control found by its accessible name, then clicked

Check the page contains text 'Subtotal'

an assertion that fails the step if it is absent

There is no generated code to maintain. The step is the artefact, and it is the thing you edit when the application changes.

Why deterministic matters here

A suite that fails at random is a suite nobody reads. The reason this one does not is that nothing in the run is probabilistic: the step compiles the same way, the element is chosen by a recorded rule, and a match below the threshold stops the step instead of guessing at it.

Expressions like a date of birth are stored as expressions, so a row on a boundary today is still on it next month.
A suite carries a content hash, so a change in the tests is distinguishable from a change in the verdict.
A refusal names what it could not resolve, which is a defect report rather than a flake.

Already have the cases in a spreadsheet? Start with the sheet you have. Working from a requirement instead? Start from a user story. Or try the steps above against our demo form.

More on the mechanics in How it works, and what is guaranteed in Guarantees.