Short answer. AI end-to-end testing uses an AI specialist to walk a product's real user journeys in a live Chromium browser session, the way a customer would, then has an independent verifier re-run every finding before it counts. It checks behaviour against requirements, not just that pages load.
What AI end-to-end testing is
End-to-end testing means checking a journey the way a user actually experiences it: start to finish, across whatever pages, forms and backend calls sit in between, rather than one component in isolation. A sign-up flow, a checkout, an onboarding wizard, a settings change that has to show up somewhere else in the product — these only prove themselves working when walked start to finish.
AI end-to-end testing adds an agent that decides which journeys to walk and what "correct" means for this product, then drives a real browser through them. The agent reads the requirements, business rules or a brief; chooses the journeys the current release could affect; opens a real Chromium session and carries out the steps a user would; and judges each outcome against a deterministic check — a URL, a page state, a network response — rather than its own impression of the screen. That last point matters: a model's opinion that a flow "looks fine" is not a result, and no amount of confident prose makes it one.
Two phrasings, one idea: people search "AI e2e testing" and "AI end to end testing" about equally. Both mean the same thing here — an agent, not a fixed script, deciding and walking the journey.
How an AI end-to-end test run works, step by step
The steps below are what separates a run worth trusting from an agent guessing its way around a website.
- Give it the journey and the intent. Which flow matters (sign-up, checkout, an admin action), plus the requirements, business rules or design system that say what "correct" looks like at each step.
- Open a real browser session. A Chromium session starts against a preview or staging build, with a test account, so the run reflects what a real visitor's browser renders.
- Walk the journey end to end. The agent carries out each step itself — filling in fields, clicking through, following redirects and callbacks — rather than checking one page or one API call alone.
- Let a deterministic check decide pass or fail. A page state, a database row, a network response or an accessibility rule; never the agent's own summary of what it saw.
- Re-run every finding independently. A failure that happened once is not yet a finding. An independent verifier repeats it in a fresh session before it is reported.
- Record what the run did not cover. An honest run says which browsers, devices or parts of the journey it skipped, rather than letting a clean report imply more than it checked.
Steps 4 and 5 are where most of the trust is earned, and they are the ones an agent cannot do by talking. Our guide to AI browser testing covers what driving a real browser does and does not prove on its own.
AI end-to-end testing vs generating end-to-end test code
"AI e2e test generator" and "AI end-to-end testing" are often used for two different things, and it is worth telling them apart before you pick a tool.
A test generator writes end-to-end test code for you, usually on top of an open-source framework such as Playwright, Cypress or Selenium, from a recording or a written prompt. You end up owning that code: it lives in your repository, runs in your CI pipeline, and someone on your team updates it when the product changes. Some generators publish their output openly, which is why "AI e2e testing github" and "AI e2e testing open source" are real searches — the automation layer underneath is frequently open source, even when the AI service on top is not.
Agentic end-to-end testing takes a different shape: instead of handing you a suite, the agent walks the journey itself on each release and reports what it found. Nothing is exported for your team to maintain between runs. The trade-off is the same one that runs through every comparison of generated code against delegated checking: a generated suite is yours to keep and speed up in CI; an agentic run needs no upkeep but produces no artefact you can inspect ahead of time, only the evidence from the run that happened. Agentic testing with Playwright goes further into where each shape fits on the code side.
Want to see an AI specialist walk your own product's journeys end to end? Start with a free 45-day trial, no card.
Work email only. We keep your email, team size and the page you joined from, only to contact you about the ShipperAG pilot. No spam.
AI end-to-end testing vs scripted test automation
Both run real browsers through real journeys. The difference is who decides what to check, and what happens when the product changes underneath the test.
| Aspect | Scripted end-to-end automation | AI end-to-end testing |
|---|---|---|
| Who decides which journeys to walk | A person, writing the test up front | The agent, from the requirements and the change |
| Who maintains it | Your team, whenever a selector or a flow moves | Nothing to maintain; the journey is walked afresh each run |
| Repeatable, identical runs | Yes — its real strength | Only as reliable as the independent re-check behind each finding |
| Cost of a UI change | Broken selectors across affected tests | Re-read on the next run |
| What you own afterwards | Test code in your repository | A release report with evidence, not test code |
| Best for | The handful of flows that must never break, run fast in CI | Checking a release against requirements without writing more scripts |
Most teams end up using both rather than choosing one. Agentic QA vs test automation goes into that split in more depth, including where a maintained suite still earns its keep. A related question, catching what a change broke elsewhere in the product rather than walking one journey, is covered in AI regression testing.
What AI end-to-end testing cannot cover
Stated plainly, because a report that hides its limits is worse than no report.
- Browsers outside Chromium. Checks here run in real Chromium sessions only, including phone and tablet sizes with touch emulation. Firefox and Safari (WebKit) rendering are not covered, and the report says so.
- Native mobile apps. This is end-to-end testing of a web product in a browser, not a native iOS or Android app.
- A test suite to keep. The output is a release report, not exported test code; there is nothing for your team to run again between visits.
- Anywhere outside the hosts you allow. Browser traffic stays inside the hosts your team permits, so a journey that would leave that boundary is not followed.
- Intent nobody wrote down. If the requirements are silent or contradictory about what a step should do, the honest outcome is "needs input", not a guess dressed up as a pass.
How ShipperAG runs end-to-end checks
ShipperAG is built around AI QA specialists, picked for each release. On a change, a coordinator reads what moved and decides which specialists to involve within the limits you set; the user journeys specialist is the one that walks a product's key flows end to end in a real Chromium browser session, following a journey through every page and step it touches rather than checking one screen at a time.
Every finding it reports then goes to the independent verifier, which re-runs it in a fresh session before it can count. Results are sealed in a hash-chained evidence ledger and come out as a release report a person can approve or share with stakeholders: verified items, issues with screenshots and steps, open questions, and a plain "not covered" section. You can see how the workflow fits together and which specialists make up the full quality map on the homepage.