Agentic QA: Why Test Automation Is Turning Autonomous in 2026

For years, “continuous automation testing” was the goal: script every scenario, run it in CI, and let coverage climb release over release. Forrester tracked that category for years — and in 2025 retired the name. Its research now covers Autonomous Testing Platforms instead, because the old model had stopped working the way the name implied.

The reason, per Forrester’s own research: most organizations had plateaued at roughly 25% test automation, no matter how much they invested in scripting. Release cycles kept shrinking while test suites kept growing, and a large share of QA time went to fixing brittle selectors and assertions every time the UI changed — not writing new coverage. Forrester’s Diego Lo Giudice put the discipline this creates plainly, invoking Andrej Karpathy’s line that teams “must keep AI on the leash”: the tooling is autonomous now, but the testing of what it produces has to get more rigorous, not less.

Agentic QA is not a rebrand of test automation — it is a different relationship between the tester and the tool. Traditional automation runs a script a human wrote, step by step. An agentic testing tool is given a goal or a running application and plans, writes, executes, and repairs the tests itself, adapting as the product changes underneath it.

The clearest evidence this is now core tooling, not vendor marketing, sits inside Playwright — one of the most widely used open-source browser testing frameworks — which now ships three official test agents. A planner explores the running application and writes a Markdown test plan. A generator turns a reviewed plan into executable Playwright test files, verifying selectors and assertions live against the real app rather than guessing at markup. A healer replays a failing test, inspects the current UI, and proposes a targeted repair — a locator update or a wait adjustment — rerunning until it passes or a guardrail stops it. All three run through the Model Context Protocol against a real browser, so decisions are grounded in actual page state rather than an LLM’s assumption about it.

A healer that can silently patch a broken assertion is also a healer that can silently patch over a real regression — loosening a check until it stops failing looks identical, in a green CI run, to fixing a stale selector. Playwright’s own documentation builds in the expectation that generated tests get reviewed before they ship, and that healer repairs are diffed like any other code change rather than trusted because the suite is green again.

That is the practical shape of “keep AI on the leash” for QA specifically: scope what an agent can touch, log every autonomous repair so it is auditable, and keep a human in the loop on anything that changes what a test actually asserts. None of that is a reason to avoid agentic QA — it is the reason it needs a QA function deciding where the leash is, not a tool running unsupervised in a pipeline no one is watching.

The work shifts, it does not disappear. Fewer hours go to writing and re-writing brittle selectors by hand; more go to writing clear test intent for the planner, reviewing generated plans and healer diffs before they merge, and deciding which user journeys get risk-based coverage at all. That is a strategy and review discipline, not a scripting one — and it is exactly the gap teams hit when testing has been developer-led by default and no one owns the coverage picture end to end, the same resourcing question we cover in Dedicated QA Team or Developer-Led Testing?

Innvente’s software testing and QA team designs risk-based coverage and CI gates before turning on agent-driven test generation or self-healing, and can wire agentic testing into your existing CI/CD pipeline rather than bolting it on separately. If you are not sure where your current coverage is thin or whether agentic QA is safe to adopt yet, start with a free software project audit — we will show you where the real risk is before you automate around it.