I keep seeing two phrases buzzing around my feed:
Agentic testing and AI-powered testing.
They are often used as though they mean the same thing. They don’t.
So let’s break this down first.
“AI-powered testing” can mean many different things.
It might mean using AI to generate tests for frameworks such as Playwright, Selenium, Cypress, or whatever testing framework your QA team refuses to stop talking about.
The QA team at my office loves Selenium and keeps pushing for it.
Insider news: I am not letting that happen while I am still here.
Jokes aside, AI-generated test code is probably the most common version of AI-powered testing today.
You give Claude, Codex, Cursor, or another coding assistant a description of the feature, and it produces a test script for you.
The result is still a traditional code-based test.
AI simply helped write it.
AI-powered testing can also mean adding intelligence around an existing test suite.
For example, you may already have Playwright or Selenium tests. When one of them fails, AI can help determine whether: AI can also analyse logs, screenshots, browser activity, and failure messages to explain what probably happened.
Another version is AI-assisted recovery.
A test fails at a particular step, but instead of stopping immediately, the system tries to understand the page and find another valid way to continue.
This is commonly called self-healing test automation.
A few years ago, doing this reliably was extremely difficult. Even now, “self-healing” is often oversold, but modern browser agents and language models have made limited recovery much more practical.
So AI-powered testing can mean: Agentic testing is slightly different.
With agentic testing, you are not necessarily writing the test implementation yourself.
You describe the user journey, expected outcome, or task in natural language.
The agent then uses the tools available to it to understand the application and execute the journey.
For a web application, those tools might allow the agent to:
For Android, iOS, desktop software, or other weird things you somehow ended up having to test, the available tools would be different.
The main idea remains the same:
You describe the goal.
The agent decides how to complete it.
This workflow does not make much sense for unit testing. Unit tests require precise inputs, outputs, assertions, and deterministic behaviour.
But it can be extremely useful for end-to-end testing.
E2E tests are about user journeys.
Can the user sign in?
Can they create an account?
Can they add a product to the cart?
Can they complete checkout?
Can they create a transaction?
Can they reach the expected confirmation screen?
These are exactly the kinds of tasks that a browser agent can understand and attempt inside a real application.
I am a developer, not a dedicated test automation engineer.
I can write tests, but I do not always know the best way to structure a serious E2E testing suite from day one.
This is probably common in smaller companies.
You may not have a full QA automation team. Management still wants important workflows covered, so the responsibility lands on whichever developer looked least busy during the meeting.
That developer may be you.
It has definitely been me.
The usual solution is straightforward.
You open Claude, Codex, Cursor, or another coding assistant and ask it to generate a Playwright or Selenium test.
The generated test looks reasonable.
It runs.
You get a green check mark.
You call it a day.
Then a few days later, somebody pushes a UI change.
A new button appears.
A label is renamed.
The page structure changes.
A table starts overflowing on smaller screens.
The main test might still pass because the original journey is technically working.
But the new button is not covered.
The overflowing table is not detected.
Or the test fails because a selector changed, and now you are asked to figure out whether the application broke or the test simply became outdated.
Adding coverage for the button is easy enough.
But what about the table overflow?
How exactly should I script that?
How do I test layout issues across multiple screen sizes?
How do I distinguish a harmless DOM change from a genuine user-facing regression?
With my limited testing knowledge, my first instinct would be to ask Claude again.
Then I would ask it to fix the first generated test.
Then fix the fix.
Then add another helper.
Then update the selector strategy.
Before long, the test suite becomes an AI-generated soup that technically belongs to me but is no longer something I confidently understand or want to maintain.
That was the problem I kept running into.
I started wondering whether the process could be simplified.
Instead of asking AI to keep generating and repairing test code, what would happen if the AI agent directly executed the user journey?
That led me toward agentic E2E testing.
The idea looked genuinely exciting.
Rather than writing every click, selector, wait condition, and fallback path, I could describe the flow and let an agent operate the browser.
So I started building a small internal testing suite around the idea.
Then I kept building.
Nobody stopped me and asked:
Where exactly are you going with this?
Honestly, I did not know either.
At first, I only wanted a better way to test my own applications.
But when the initial version started working, I could watch the agent interact with the application in real time.
It would open the browser, inspect the page, navigate through the user journey, fill forms, make decisions, and report what happened.
I could see the web application being tested live instead of staring at a terminal and waiting for a pass or fail message.
More importantly, the final result included useful context.
Not just:
Test failed.
But information about where the agent got blocked, what it expected to find, what it actually found, and what might have caused the problem.
That small experiment slowly turned into an MVP for an agentic E2E testing platform.
And eventually, CueTest came out of it.
CueTest is an agentic end-to-end testing platform for web applications.
You describe the user journey using natural language.
CueTest runs that journey against your staging or deployed application using an agent inside a real hosted browser.
While the test is running, you can watch the browser session and follow the live execution logs. The agent can:
The important difference is that the test is based on the intended user journey rather than a fixed sequence of selectors.
For example, suppose your original instruction is: Sign in, open the beneficiaries page, create a new beneficiary, and verify that it appears in the list.
Later, the UI changes.
The button moves.
The wording changes from “Add beneficiary” to “Create beneficiary.”
The form layout is updated.
A traditional test may fail because the implementation changed, even though the user journey stayed exactly the same.
An agentic test may still complete the journey because it is trying to achieve the goal rather than blindly replaying one exact sequence.
That does not mean the agent will magically survive every redesign.
It will not.
Agentic testing is not magic, and it is definitely not perfectly deterministic.
But when the journey remains the same and the UI changes slightly, the original natural-language test can often continue working without being rewritten.
When the journey itself changes, you update the description.
Instead of refactoring a large test script, you explain the new flow.
I do not think agentic testing will completely replace Playwright, Selenium, Cypress, or other code-based testing frameworks.
Code-based tests still provide more precise control.
They are better when you need:
Agentic testing offers a different trade-off.
It can make tests faster to create, easier to understand, and more adaptable to smaller UI changes.
It can also make E2E testing more accessible to developers, manual QA testers, product managers, and small teams that do not have the resources to build and maintain a large automation framework.
The strongest approach will probably be a combination of both.
Use code-based tests for critical workflows that require maximum predictability.
Use agentic tests for broader user journeys, rapidly changing features, exploratory coverage, and scenarios where writing and maintaining a full scripted test would be too expensive.
Getting an AI agent to click buttons is not the hardest part.
The harder part is building a testing system that teams can understand and trust.
The agent needs boundaries.
It should not keep retrying forever.
It should not invent credentials.
It should not randomly explore unrelated pages.
It should not mark a test as passed simply because it managed to click through several screens.
It needs clear objectives, visible execution, limited recovery, meaningful stopping conditions, and useful failure analysis.
That is the part I am continuing to work on with CueTest.
The real question is not whether an AI agent can operate a browser.
It clearly can.
The more interesting question is:
How much uncertainty are teams willing to accept in exchange for faster test creation, broader coverage, and lower maintenance?
I would genuinely like to hear how other developers and QA engineers see this.
Which parts of your E2E test suite would you trust to an agent?
And which parts would you always keep code-based?
I am building CueTest, an agentic E2E testing platform for creating and running browser tests from natural-language user journeys.
You can check it out at ** cuetest.dev**.
This article is based on my own experience building CueTest. I used AI to help organize and polish the writing, but the technical decisions, product experience, opinions, and questionable Selenium jokes are mine.