For two decades, writing an end-to-end test meant knowing a framework. You learned Selenium's waits, or Cypress's chaining, or Playwright's locators, and that knowledge was the gate. If you couldn't write the code, you filed a ticket and waited for someone who could. The person who understood the product and the person who could encode a check for it were usually two different people, and the handoff between them was where coverage went to die.
That gate is coming down. Agentic testing tools take a plain-language description of a behavior and produce a real, running test, which moves the qualification for authoring one away from knowing a framework and toward being able to say clearly what the app should do. Far more people can do the second thing than the first.
The role shift, stated plainly
Industry analysts have been calling this for a while: as AI agents absorb the mechanical parts of test creation, the QA role moves from writing scripts toward orchestrating coverage and risk. The reports keep reaching for the word orchestrator, and the shift underneath the vocabulary is real. The scarce skill has moved from operating the framework to deciding what gets tested and why.
Think about what actually happens when a PM writes this:
A signed-out user who adds an item to their cart and then signs in still has the item in their cart.
That sentence is a regression test. It names a starting state, an action, and an observable outcome, which is enough for a machine to drive a browser through it and for a human to tell whether the result is right. The PM didn't write a single await page.click(). They authored a test anyway. The hard part of a test was never the syntax; it was knowing that cart persistence across sign-in is something real users hit and something that quietly breaks in a release nobody thought went near the cart.
We've already watched this play out on the coding side, where the day-one story on agent-assisted codebases is a non-framework-expert shipping a real contribution because the tool closed the gap between intent and implementation. Testing gets a stronger version of the same effect, because a test is already a specification of intent, and a specification of intent happens to be the one thing that's easy to write in plain language and miserable to hand-code.
What plain-language authoring actually buys you
The real payoff here is proximity: the people closest to a behavior can encode it directly, instead of describing it to someone else and hoping the translation survives the trip.
- The support lead who sees the same broken flow in tickets every week can write a test for it instead of describing it in a Jira comment and hoping.
- The designer who knows the empty-state and error-state paths that engineers forget can pin them down.
- The PM who wrote the acceptance criteria can turn each criterion into an executing check, because acceptance criteria and test descriptions are nearly the same artifact.
The quality of the resulting test tracks the quality of the description rather than the framework fluency of whoever wrote it. A vague spec ("test the checkout") produces a vague test. A sharp one ("a user with an expired card sees a decline message and stays on the payment step, cart intact") produces a sharp one. Writing the sharp version is a learnable skill, and it's the one that matters now; we wrote a whole guide on writing test descriptions that generate good tests because that is where the leverage moved.
Gherkin as the shared contract
When authoring opens up to a whole team, you need a shared format everyone can read — precise enough to be unambiguous, plain enough that a non-engineer can review it. Gherkin's Given/When/Then does exactly this, which is why it survives as the lingua franca even when nobody's hand-writing step definitions anymore.
Scenario: Cart survives sign-in
Given a signed-out visitor has added a "Trailhead Jacket" to their cart
When they sign in with valid credentials
Then the cart still contains the "Trailhead Jacket"A PM can read that and confirm it's the behavior they meant. An engineer can read it and know exactly what the generated Playwright will drive. The dual readability is the whole point, because it lets both sides sign the same artifact. You don't have to require Gherkin to get value out of generated tests, and not every team needs it, but as a shared vocabulary between product and engineering it earns its keep exactly when authorship spreads past the framework experts.
What stays expert work
None of this makes QA a solved problem, and it doesn't make QA engineers redundant. It moves their value somewhere else. Once mechanical authoring gets cheap, the skills that stay scarce are the ones that take judgment:
- Risk prioritization. A team can now generate a thousand tests. Which forty matter? Knowing that the payment path deserves ten scenarios and the About page deserves zero is domain judgment no model has. When everyone can author, someone has to decide what's worth authoring.
- Exploratory testing. Scripted checks confirm what you already suspected could break. Finding the failure nobody thought to describe — the one that only happens on a double-click, or with a pasted emoji in the name field — is human, curious, adversarial work. Agents automate the regression suite; they don't replace the person poking at the app trying to break it.
- Judging coverage quality. A green suite of shallow tests is more dangerous than a small suite of deep ones, because it feels like safety. Reading a spec and asking "does this assertion actually pin the outcome, or does it just check that a page loaded?" is the reviewer's job, and it's the difference between a test that protects you and one that lies to you.
That's what the orchestrator role means once you spell it out. The QA lead still tests. What changes is that the day fills up with pointing an abundant authoring capacity at the targets that matter and guarding the quality bar on whatever comes back. They stop being the bottleneck who has to write every script personally, and they start owning the risk model that the whole team now writes against.
This is also why the workspace matters more, not less. When a PM, a support lead, and three engineers are all authoring against the same app, you need shared team workspaces where specs, runs, and coverage live in one place instead of scattered across branches and heads. And the whole shift is the logical end of shift-left: quality stops being a phase that a separate team runs at the end and becomes something everyone who touches the product contributes to from the start.
Where this leaves you
The teams that pull ahead won't be the ones with the most framework experts. They'll be the ones that turn product knowledge into executing checks with the least friction, and then spend their senior QA judgment on the questions a machine can't answer: what's risky, what's untested that should be, and whether a passing test is actually telling the truth.
Want to see what it looks like when a plain-language description becomes a running, verified test? Get early access, or read how generation works.