QA engineer automation in 2026: writing plans an agent runs, not selectors

The job has split. The execution layer (clicking, typing, asserting) is now an agent that drives a real browser through Playwright MCP. The authoring layer (deciding what to verify and how to phrase it) is a human writing plain-English steps in a Markdown file. A QA engineer in this model spends almost no time on locators and most of their time on `#Case` blocks, expected outcomes, and edge cases. It is closer to writing a good bug report than writing code.

The agent in Assrt cannot call arbitrary Playwright. It can only call 18 named tools defined in `/Users/matthewdi/assrt-mcp/src/core/agent.ts` lines 16 to 196: navigate, snapshot, click, type_text, select_option, scroll, press_key, wait, screenshot, evaluate, create_temp_email, wait_for_verification_code, check_email_inbox, assert, complete_scenario, suggest_improvement, http_request, and wait_for_stable. Anything else is a schema error rejected by the MCP server. The QA engineer never picks one of these; the agent does. The QA engineer only writes the English in `#Case` blocks.

Each step that needs to touch an element starts with a `snapshot` call. Playwright MCP returns the page as an accessibility tree and tags every focusable element with an opaque ref like `e5` or `e12`. The agent then calls click or type_text passing the ref it just saw. The lookup happens on the live page, so a UI redesign that keeps the same accessibility role does not break the test. There is nothing in the plan that says `.btn-primary` or `[data-testid=submit]`. The plan says `Click the Sign In button` and the runtime resolves that string to an `e7` at run time.

Four paths, all under `/tmp/assrt/` by default. `/tmp/assrt/scenario.md` is the plan, written in Markdown with `#Case N: name` blocks. `/tmp/assrt/scenario.json` carries the metadata (id, name, url, updatedAt). `/tmp/assrt/results/latest.json` is the most recent run, with per-assertion evidence strings. `/tmp/assrt/results/<runId>.json` archives history. Save scenario.md in any editor and an fs.watch in `scenario-files.ts` re-syncs the plan after a 1000ms debounce. There is no proprietary editor between the engineer and the file.

Three concrete differences. First, the artifact: Selenium and Playwright deliver `.spec.ts` or `.py` files; Assrt delivers Markdown. Second, the resolver: Selenium and Playwright bind to selectors at write time; Assrt binds to accessibility refs at run time. Third, the loop: traditional automation runs deterministic code; an agent loop reads the page after every action and decides the next move. The classic stacks are still useful (Assrt drives Playwright underneath, after all), but the QA engineer's authoring surface is no longer a typed locator API.

It shifts it. The work that survives is the part agents are bad at: deciding what edge cases matter, writing assertion text the customer would care about, classifying a failure as app-bug versus test-flaw, and deciding when a flake is real. Assrt has a dedicated tool for the last one called `assrt_diagnose` that returns a senior-QA-style verdict (bug in app, flaw in test, or environment) plus a corrected `#Case` you can paste back. The mechanical click-and-type work is what the agent absorbs.

Write outcomes, not interactions. `Click Add to cart` is fine; `Click button.btn[data-testid=add]` is wrong because the engineer is now doing the agent's job. State preconditions explicitly (`as a signed-in user`), name expected results in plain text (`subtotal shows $24.99`, `the URL ends with /thanks`), and prefer one verifiable assertion per step over a long chain of clicks ending in a single check. The goal is for any contributor to read the case and understand both intent and expected behavior without opening the app.

Two of the 18 tools exist for exactly this: `wait` and `wait_for_stable`. `wait_for_stable` is the better default because it polls until the DOM stops mutating for N seconds, rather than sleeping for a hard-coded interval. The engineer does not call these directly. Instead, the plan describes the user-visible cue (`Wait until the order summary appears`) and the agent picks the appropriate tool. If a case still flakes, `assrt_diagnose` looks at the run trace and proposes the right wait strategy.

Yes. The format is plain Markdown, so `git diff` shows exactly what changed between revisions. Many teams copy the plan out of `/tmp/assrt/scenario.md` into a versioned `tests/scenarios/` directory once it stabilizes. Pull request review then becomes a Markdown review: did the case capture the intent? Are the expected outcomes specific? Code review for QA goes from selector audits to product review, which is what most senior reviewers wanted to do anyway.

Locally. Assrt is open source, self-hosted, and the agent runs entirely on your machine through `npx assrt`. Tests, plans, screenshots, and recordings stay in `/tmp/assrt/` and `~/.assrt/` unless you sync them yourself. Cloud sync is opt-in and uses UUIDs as access tokens, not account-bound storage. Compare to closed-source tools that price per-test-run and own the resulting fixtures: with Assrt the markdown is yours, the WebM is yours, the JSON report is yours.

Yes. Assrt does not replace an existing Playwright suite, it runs alongside. Keep the deterministic `.spec.ts` files for the flows the team has already invested in. Use Assrt for the work that benefits from English-first authoring: exploratory tests, regression cases that change frequently, customer-reported flows that need to be turned into verification quickly. Both stacks ultimately drive Playwright; only the authoring surface differs.