The person who knows an important product behavior may not know how to write a Playwright test. A plain-language scenario lets them record the starting state, action, and expected result. QA and developers can then review the requirement, generate or write the check, and inspect its execution.
Generation can help turn that description into executable code. It broadens the ways people contribute to a suite while preserving expert work: coverage decisions, state setup, assertion review, and failure investigation.
The role shift, stated plainly
Tricentis's January 2026 conference recap describes QA leaders becoming orchestrators who define quality objectives and oversee AI-driven outcomes. That is a vendor's account of the trend, rather than proof of an industry-wide role change. For your own team, the practical question is who decides 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 requirement; it still needs an implementation, suitable state and verification. 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 authored the intended behavior without writing a browser command. 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.
The cart-persistence example shows a useful division of work: the PM names the requirement, QA checks the edge cases, and a developer or generator implements the assertion. Everyone can review the scenario without pretending that readable intent alone is a finished test.
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 description gives the generator clearer evidence to work from; inspect whether its code actually checks those outcomes. 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 compare it with the generated code to see whether the implementation matches. 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 requires accountable domain judgment. 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.