A QA automation career built on Playwright, in 2026, when an agent is the one writing the locators

What actually moved

For about a decade, the work that paid in QA automation was “turn this Jira ticket into a deterministic Playwright test.” You read the acceptance criteria, opened the app, dug through the DOM, picked a stable selector, wrote the case, watched it flake, tweaked the wait, watched it pass. Hours per case. Most of those hours were not the interesting part; the interesting part was deciding what to test and what to assert. The rest was glue.

The glue is the part that compresses. An LLM driving Playwright through the Playwright MCP server can take a paragraph of plain English (“add SKU-7842 to cart, verify subtotal increments by $19.99”), inspect the page, find the element by accessibility role, click it, and emit a structured pass or fail. It is not magic; it gets confused, it occasionally hallucinates a button, it sometimes needs a sharper pass criterion. But the average time-per-case has dropped enough that the rest of the day rebalances around the decisions that did not compress: what to test, what counts as passing, and what to do when the run is red.

The new loop, on one screen

If you are coming from a 2022-shaped Playwright job, this is the part that will feel different. The artifact you ship is no longer the `.spec.ts` file. The artifact is the plan and the report.

The exact MCP tool surface, if you want to verify this against source rather than take my word for it, lives in assrt-mcp/src/mcp/server.ts: three tools (assrt_test, assrt_plan, assrt_diagnose), with the schema for each defined inline starting around line 343. The default model is claude-haiku-4-5-20251001; you can override it.

The artifact: what a `TestReport` actually contains

This is the moment the career conversation gets concrete. The shape you stare at every day is defined in assrt-mcp/src/core/types.ts. A run produces a TestReport with a list of ScenarioResult, each scenario carrying its own TestStep[] and TestAssertion[].

// assrt-mcp/src/core/types.ts
export interface TestStep {
  id: number;
  action: string;
  description: string;
  status: "running" | "completed" | "failed";
  reasoning?: string;
  error?: string;
  timestamp: number;
}

export interface TestAssertion {
  description: string;
  passed: boolean;
  evidence: string;
}

export interface ScenarioResult {
  name: string;
  passed: boolean;
  steps: TestStep[];
  assertions: TestAssertion[];
  summary: string;
  duration: number;
}

export interface TestReport {
  url: string;
  scenarios: ScenarioResult[];
  totalDuration: number;
  passedCount: number;
  failedCount: number;
  generatedAt: string;
}

Read the fields slowly. The reason the job did not vanish is right here. reasoning is a free-text field where the agent says why it did what it did at that step. When a case fails, you read error against reasoning against evidenceand decide whether the app shipped a bug, your plan was loose, or the environment flaked. Nobody else on the team is going to do that for you. That is the job.

What writing a `#Case` actually looks like

Here is a real plan against a fake checkout. It is the level of specificity that produces a reliable run. Vaguer plans flake; tighter plans are slower to write but cheaper to live with.

#Case 1: Add to cart updates subtotal
Navigate to /products/SKU-7842.
Click the "Add to cart" button.
Verify the cart drawer opens and shows the line item
"Blue Hoodie L" with quantity 1 at $19.99.
Verify the cart subtotal in the header reads "$19.99".

passCriteria:
The cart drawer is visible, the line item exists, and the
header subtotal reads exactly "$19.99". If anything else
is in the cart, this case fails.

#Case 2: Removing the only item empties the cart
Open the cart drawer (assume Case 1 ran first).
Click the "Remove" button next to "Blue Hoodie L".
Verify the cart drawer shows the empty state with the text
"Your cart is empty" and the header subtotal reads "$0.00".

passCriteria:
The empty-state text is visible, the line item is gone, and
the header subtotal reads exactly "$0.00".

Notice what is and is not in there. There is no XPath, nodata-testidchain, no waiting strategy. There is the user goal, the inputs, and a sharp pass criterion. The agent figures out the locator and the wait. The career skill is writing the rest of it well.

How a request actually flows

If you have used MCP before, this will look familiar. If you have not, it is the part of the new world worth understanding before you take a job that says “Playwright + AI” in the JD.

The agent never sees a CSS selector. It sees an accessibility ref like ref=e5 attached to a role-and-name pair, and it acts on that. This is why the new plans read human (“the Add to cart button”) rather than mechanical (“[data-testid="add-to-cart"]”). It is also why the trade is real: you give up some determinism for a lot of ergonomics, and the structured report is what puts the determinism back.

The triage move that separates senior from junior

Anyone can write a plan. The career is built on what you do when the report comes back red. The agent will tell you it could not click the “Sign in” button. A junior runs it again. A senior reads the run video, opens assrt_diagnose, reads the proposed hypothesis, then makes one of three calls.

The reason this is the senior move is that the cost of getting it wrong compounds. A flake you mis-classify as an app bug eats engineering time. An app bug you mis-classify as a flake ships to production. The triage muscle is what gets paid in 2026, and it is the thing nobody is teaching on YouTube because it does not look impressive in a thumbnail.

Open-source matters more than it used to, not less

If you are picking the stack you are going to build a career on, picking the closed platform that costs $7,500 a month and outputs proprietary YAML is not the bet it looks like. Two years from now the test plans you wrote on it are not portable, the diagnoses you produced are locked in someone's dashboard, and the resume signal is “I am fluent in a vendor.” The Playwright + open-source-agent path produces artifacts that live in your repo: a plan file, a report JSON, a video. They are yours. They are also the artifacts a hiring manager can actually look at.

This is one of the reasons we built Assrt as the open-source variant. The MCP server, the CLI, and the test agent are all on GitHub. The default model is claude-haiku-4-5-20251001 but you can swap it. The reports land on disk under /tmp/assrt/. Nothing is hidden behind a login wall you might lose access to.

A 30-day plan if you are mid-career and reorienting

Concretely, what would I do if I were a five-year QA engineer reading this thread on a Sunday night, slightly worried about the next two years?

1. Week one. Re-read the Playwright best-practices doc. Make sure your Page Object instinct is current. If you cannot explain what an actionability check is in two sentences, fix that first.
2. Week two. Stand up an agentic runner against a personal app. With Assrt: npx @m13v/assrt setup, then npx @m13v/assrt run --url http://localhost:3000 --plan-file plan.txt --json --video. Read the resulting report end to end.
3. Week three. Convert one real suite at work to plans. Pick the flakiest `.spec.ts` you own. Rewrite it as `#Case` blocks. Keep the original. Run both for two weeks; compare the failure modes. This is your portfolio writeup.
4. Week four.Wire the new runner into a PR check. Even on a personal repo. The CI snippet is the third resume artifact. Two thousand words of Medium prose about “the future of QA” will not move a hiring manager. A working PR check will.

Frequently asked