Legacy vs Autonomous QA Arena [Testμ 2026]

The Broken Morning

He opens by asking for a show of hands from anyone who has lived the scenario: a full day building a suite, everything verified, then every test failing the next morning.

He walks the diagnosis aloud, ruling out the application and a database crash, and lands on a moved locator or an updated CSS class taking down every case.

His classification of the episode is the part that matters for the rest of the talk. It is a false positive, because you found everything except the actual defect.

He introduces himself in the same breath: senior manager at Equifax, 18 years of experience, having worked as a QA engineer, moved through automation into development, and now managing both a development and a QA team.

He sets four rules for the session, treating it as a workshop rather than a lecture, and invites questions in the chat at any time.

Spot The Flaky Test

He puts up what he calls a real execution log, showing an element-not-interactable exception on a checkout button that will not click. It is a slide, not a terminal.

Three candidate causes sit on the slide: a broken XPath, a dynamic DOM re-render, or an unhandled timing delay. He asks the audience to form a guess, and reveals the answer himself about twenty seconds later. No vote was taken, despite the description promising the audience would vote on real failure logs before the root cause was revealed.

The answer is an unhandled timing failure caused by a micro-animation the script never waited for.

He then delivers the two headline numbers. Timing and locator issues account for 58% of all test failures, and 40% of a typical QA team’s budget goes into maintaining that category. He states the 58% two different ways minutes apart, once as timing alone and once as timing and locator combined, which are not the same claim.

His framing line for both is that this is not a tooling gap, it is the line item. The published description restates the budget figure as a 30 to 40% range, which he never says.

Selenium Rescoped, Not Retired

He calls Selenium paired with the page object model the undisputed king of the past decade, and flags his own take as a little controversial before making it.

His stated 2026 position is that 65% of organisations still use and maintain legacy Selenium suites. He attaches a figure above 200% to the newer frameworks, though the sentence carrying it is damaged in the recording, so the growth claim is only unambiguous later in his quiz answer key, which uses a different number again.

He explains the mechanical difference between the two approaches in terms of how each talks to the browser, one through an external wrapper and one directly. The sentence is garbled at exactly the point where the technical claim sits, so it is not reproduced here.

Asked directly whether Selenium is dying, his answer in the talk is no, and that it will probably continue for the next ten years, with the change being a rescoping rather than a death.

He takes the opposite position later in the session. During the quiz he says the trend is decreasing, that Selenium will eventually time out as people move to the latest frameworks, and that the new framework becomes the baseline. Both statements are his, roughly forty minutes apart, and he never reconciles them.

His practical rule is consistent across both, though: a staggered wave rather than a port. Keep the existing regression baseline in Selenium and route new features, new products and new enhancements to Playwright, Cypress or an AI-native platform.

Cucumber BDD As Tech Debt

He walks the legacy behaviour-driven chain by hand: product owner, tester, developer, QA and sometimes the business collaborating on a feature file, the given-when-then becoming the test case, step definitions following, then page object model classes for each page.

He is explicit that he is not writing it off. The framework has always worked, and he says he is not claiming it is going away or that it is not good.

His actual complaint is maintenance cost. Maintaining step definitions has become tech debt, because every change means going back to the definition, updating it, and re-syncing with the issue tracker and the documentation.

He calls the budget spent merely maintaining the framework enormous, without attaching a figure to that particular claim.

His alternative is a plain-English prompt covering the whole end-to-end journey, returning resilient test code from an AI-native platform rather than hand-written step definitions.

He then drops the adoption gap that recurs through the session: 89% of enterprise teams piloting generative AI against 37% reaching production, and asks whether the gap is understanding, evolution, or both. Like the rest, it arrives without a source.

Architecture, Not Tools

Asked what actually changed, he rejects both obvious answers. Not the tools, not the infrastructure. The architecture.

He describes the legacy pipeline as strictly linear and glued together, running from requirement through feature file and page object model to execution, a CI pipeline, a cloud grid and a static report.

His objection is failure propagation rather than slowness. Every layer is deterministic, and if one layer breaks it takes the entire journey with it. Replay is possible and he calls it time-consuming, cumbersome and bulky.

The modern architecture in his framing does not replace that chain. It wraps an adaptive layer around it, with AI test selection, self-healing resolvers and live risk analytics sitting on top of the existing foundation.

He is consistent that the foundation stays put, and that the critical piece is how you leverage it rather than whether you replace it. That is the same argument he uses later against rewrites.

Three Layers Of Healing

His worked example is an e-commerce checkout button whose class changes from a stable name to a dynamic CSS hash on deploy. Identical text, identical position, identical colour, and the application behaves the same, while the test fails immediately because it is looking for something that no longer exists. He claims a human could never catch it, which is his phrasing rather than a demonstrated fact.

He then breaks self-healing into three measurable layers rather than a black box.

He grants that Selenium has built-in actions covering some runtime cases, and argues auto-healing handles them better.

All three percentages return later as answer keys in his quiz. He reads out the correct answer each time and never reports how the audience actually answered, so nothing in the session corroborates these figures from the room.

The Human Approval Gate

His answer to what an agent still cannot do is governance. An agent can confidently draft what you asked for through a prompt, and it can also go badly wrong, which is where the human in the loop comes in.

He ties the risk to development-side AI adoption. Teams shipping at twenty or fifty times their old pace are introducing bugs they cannot explain, because they do not understand how the generated code works.

His asymmetry argument is blunt. Nobody on the development side is asking what generation is doing to the foundation, and it becomes QA’s responsibility to make sure it is handled, regardless of which tool produced the code.

The concrete form of this is a project he gave his team, which he dates only as around March or April and hedges even that. On a framework that had already matured from Selenium through Cypress to Playwright, multiple agents now watch the application across development and test regions. When a CSS selector or anything else changes, an agent updates the script autonomously and then reports to a human what it saw and what it implemented, for approval.

Only after approval does the code get checked in automatically and the pipeline trigger. No metrics, failure rates, screenshots or code accompanied any of this.

His first-hand case for why the gate exists is the strongest material in the session. A monitoring agent was reasoning confidently about an application that was not actually running, because it had been deployed to the wrong network, so the agent was in effect observing something else entirely. He likens it to a knowledge cutoff problem.

QA Grew Faster Than Dev

His slide claims QA engineer roles grew 17% against 9% growth for developers, and he tells the audience to remember it because it will appear in the quiz. The timeframe shifts inside the session: the slide says last year, and his own quiz asks about growth over the past two years.

His explanation is that AI-generated code creates edge-case defects and stale code that hand-written code did not produce. Half of what is generated might be stale, in his phrasing, and it might fix one thing while breaking another.

That is why he says regression testing matters again. A fix can drag baggage into the architecture that even the development team cannot explain, because the snippet was generated rather than reasoned through.

The top-skills slide he reads out covers prompt engineering, risk-based test strategy, systems thinking and AI governance. A fifth item is garbled beyond recovery in the captions and is left out here.

He argues QA has already survived this kind of shift before, from manual testing to automation to performance to full lifecycle ownership, so the agentic step is continuity rather than displacement.

Migrating Without A Rewrite

Asked how enterprise teams safely migrate a large legacy page object model suite without a complete rewrite, his answer is to stagger rather than port. New features and new platforms go to the new framework while the Selenium suite moves slowly behind them.

His reasoning against a rewrite is sunk value. What has been built over time has proved it works for the team, so he does not want to spend heavily moving it.

His counterweight against doing nothing is decay. Start now, or the framework ages, stops being maintained, and the baggage grows daily.

Asked what workload still justifies scripted Selenium specifically, he gives the clearest workload-level answer in the session. If the application is not changing, the project is not moving much, and you are only maintaining the regression suite, he would not move to a new framework.

Asked what benchmark signals readiness for total replacement, he does not answer that half at all. He argues instead that the shift is here for good, because Selenium has accumulated a decade or more of bulk and a single-step failure can break the whole linear framework. No benchmark, threshold or readiness signal is named.

One question went unanswered entirely. An attendee asked about heavily regulated industries such as finance and healthcare requiring strict audit trails. It was read aloud and he moved straight to the next question. No compliance or audit-trail content appears anywhere else in the session.

Thresholds And Going Slow

Asked whether a confidence score sits behind self-healing actions, with low confidence routed to a human and high confidence proceeding automatically, he says the threshold is a team decision rather than a product default.

His recommended sequence starts conservative. When the agent is first set up the threshold might be very low, with the human as the primary point of contact, and it rises as both the application and the agent mature.

Above the threshold he would let the agent auto-approve and commit the update, or push the change into a non-production environment and re-run it there, with a second agent promoting between environments once it passes.

His governing rule is that it all comes down to how you design it, and not at the cost of something breaking drastically, so his advice is to go slow and speed up only once the system has earned it.

He concedes false positives without quantifying them, saying his team has seen examples and that it is not 100% accurate. His defence is comparative rather than absolute: with a human in the loop and live monitoring it can go wrong, but it cannot go horribly wrong. That concession is the honest counterweight to the healing percentages.

Grounding Against Drift

Asked what happens when an agent misunderstands a legacy business rule, his first answer is test-case specificity. Written as detailed as possible, the agent generally understands it correctly.

His named failure mode is knowledge cutoff. If a feature changed drastically and the model was not retrained, the agent hallucinates and treats the stale behaviour as expected.

His fix is retrieval and grounding kept current continuously, adding new features on top of the existing baseline rather than refreshing in batches.

He describes the monitoring agent as more like a live retrieval layer, watching the running application and accumulating understanding of it over time.

Alongside it his team built what he calls a corpus repository, fed with documents, requirements and tickets, so the agent learns what is changing on the business and requirement side rather than only from the DOM.

Where the agent still cannot understand something, the fallback is unglamorous. The existing team writes a new script or enhances the existing one by hand.

Q & A Session

Roughly twelve minutes of open Q&A ran mid-session, with more questions taken later. A live browser quiz filled the closing stretch, and two audience polls were run whose results were never reported on air.

• How should autonomous quality shift upstream into the pull request, the IDE and the terminal without slowing development?

  Athresh Guruprakash: The coding agents are already embedded in the IDE. Select a page, state the new feature you want, and let the agent base the new test on the existing tests and scripts already in the repository plus the observed behaviour of the application. That is at least two to four times what an automation engineer would do. He offers no baseline, task definition or measurement method for that figure.

• How does a tester’s value shift from writing test steps to supervising autonomous agents?

  Athresh Guruprakash: Agents watch for change across development and test regions, update the scripts autonomously when a selector moves, and surface each change to a human for approval before automatic check-in and the pipeline trigger. That monitoring project is the most concrete material in the session, and he gives no metrics, no failure rate and no artifacts.

• How do you prevent AI from reproducing the weaknesses of legacy QA?

  Athresh Guruprakash: Think of an agent like a child: you cannot expect it to master everything on day one, and it learns from its own mistakes. In the legacy flow a failure means a screenshot and a video, a human deciding whether it is a real bug or a renamed class, then a manual locator update and a re-run. The healing flow identifies whether the application or the structure changed, and patches it. He opens with the analogy rather than a mechanism, and never addresses the risk the question actually raised, that an agent trained on a weak legacy suite inherits its blind spots.

• Is chaos engineering or penetration testing a good subset of risk-based testing?

  Athresh Guruprakash: Security testing would be the last thing AI takes over. Penetration testing goes at your URLs, your database handling and your actions, so it should stay with a human. Perhaps we are 20 to 30% of the way there, no more, while functional, regression, sanity and performance testing are considerably easier for AI. On my own teams we are there, but not completely there. He hedges that estimate twice and effectively skips chaos engineering.

• What is the retraining path, and where has resistance come from?

  Athresh Guruprakash: I disagree with the premise. The QA-versus-developer growth numbers show the QA role is more important than any other. Later, during the poll segment: take the training, start slow, and give it six months platform by platform. That is largely a non-answer on both halves. He names no curriculum and does not say which resistance source he has actually encountered.

• When self-healing goes wrong, how much traces back to the human decision versus the human-authored test?

  Athresh Guruprakash: There are false positives. When the application fails, the system starts looking at what could have changed: whether the DOM moved, whether the structure moved, whether something that previously worked has shifted, and it records all of that over time. Where false positives occur, you correct them so the platform copes next time. He concedes them directly without offering a rate or the breakdown the question asked for.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.