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.
What does AI-powered testing actually mean? “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: The application is genuinely broken The test is outdated A selector changed The failure was caused by timing or flaky behaviour The user journey itself has changed 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: Generating test code Analysing test failures Updating outdated tests Recovering from broken selectors Explaining whether a failure came from the product or the test Agentic testing is slightly different.
What is agentic E2E testing?
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: Inspect the current page Find interactive elements Click buttons Fill forms Navigate between screens Read visible content Check whether an expected result appeared Recover when a small UI change blocks the original path 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.
The problem I had with traditional test automation 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 a