Manual QA knowledge needs an execution engine
You already know how to test. This runs it.
Test automation usually asks a manual tester to become a developer first. This does not: the knowledge you have is the input, and the parts you would have had to learn — selectors, waits, page objects, a test file — are the parts the product does.
What this does not do
It does not decide what to test, and it does not judge whether a result is acceptable. Both of those are yours. It also does not read a vague step: "the form should work" comes back unparsed, because there is nothing in it to check.
The division of labour
You write
The steps, in the words you already use. What to do, and what should be true afterwards.
This is the part nobody can automate: knowing what is worth testing and what "correct" means.
The Knowledge Base understands
Which field is "Email Address" on this application, which control is "Submit", what a dropdown on this page contains — learned from one exploration of your app.
This is the part that used to be a selector you maintained by hand.
The rules translate
Each line is compiled into an action by a grammar. A line it cannot place is refused and named rather than guessed at.
The same line compiles the same way every time, so two runs are comparable.
Playwright executes
A real Chromium session: real navigation, real clicks, real form submission.
The engine an automation engineer would have written against by hand.
You review
A step log with the result and the strategy that found each element, a screenshot per step, and a video of the session.
A green tick you cannot check is worth nothing. This is what makes the tick checkable.
What you review afterwards
A real run. The right-hand column is the part that matters to a reviewer: it names the strategy that found each element and how long the search took, so a pass can be checked rather than believed.
| Step | Action | Result | What the engine recorded |
|---|---|---|---|
| 1 | note | SKIPPED | Continue from previous step on same browser window |
| 2 | click | PASS | click -> href-first goto -> /dashboardstrategy click.href-first · 668ms |
| 3 | readvar | PASS | readvar -> page3 = "PG-01" (definition-list)strategy readvar.definition-list · 2ms |
| 4 | readvar | PASS | readvar -> session3 = "45b3285a" (definition-list)strategy readvar.definition-list · 0ms |
| 5 | assertvalue | PASS | assertValue -> "PG-01" equals "PG-01" (text comparison) |
| 6 | assertTitle | PASS | assertTitle -> "Dashboard | Fixture" |
Both are runs against our own test fixtures, so the URLs are local and the titles say “Fixture”. The statuses, strategies and wording are exactly as the engine wrote them.
What changes on your side
- You stop re-running the same regression pack by hand on every release, and start reading its evidence instead.
- A step that used to be "click the blue button" becomes a line that names the control, because the engine needs to know which one you meant.
- A failure arrives as a named step and a named reason, which is the same thing you would have written in the defect anyway.
See it on your own cases — the case you already wrote — or try a step against our demo form.
The same product, from another angle
- Automate manual test casesThe test case you already wrote, run as it is written — with a step log and evidence.
- From a spreadsheetUpload the sheet you already maintain. Two columns, one row per case.
- Playwright without the codePlaywright executes it. You never open a test file.
- Regression suitesRe-run the BAU suite on every release and compare it against the last one.
- EnterpriseSSO and MFA, masked fields, long multi-step flows, and one organisation per tenant.