End-to-end testing services with AI agents, reviewed by engineers

Why end-to-end suites stall

End-to-end tests check the product the way a user uses it, which is why teams want them and why they are hard to keep. Three things usually go wrong.

• Writing is slow. Each journey needs a plan, test data, locators and waits. The suite grows more slowly than the product, so coverage falls behind.
• Upkeep eats the gain. A changed button, a renamed field or a new modal breaks tests that were correct the day before. Engineers spend their time repairing tests instead of finding defects.
• Nobody trusts a red build. Once some failures are flaky, people re-run and ignore. A real defect then looks like another flake.

AI agents help with the first two. They can explore a page, draft a test from a plan and propose a repair when a locator changes. They make the third problem worse if nobody checks their work, so review is part of the service, not an add-on.

How the work is done

1. Plan. For each journey we write a short test plan in plain language and agree it with you.
2. Draft. An agent drafts the test against your test environment, using your framework and conventions.
3. Review. An engineer reads the test as a pull request: is the assertion the business rule, are the waits sound, is the data isolated, would this test fail on a real defect?
4. Run. The test runs in your CI. Failures are sorted into defects, test faults and environment faults.
5. Repair. When the interface changes, an agent proposes a repair. An engineer approves or rejects it, and a rejected repair often points to a real bug.

What the review checks

Area	Example checks
Assertions	The test checks the business rule, not only that a page loaded
Locators	Role, label or test id in preference to brittle CSS paths
Waiting	Waits on page state, never on a fixed delay
Data	Each test creates or resets its own data and does not depend on the order of other tests
Repairs	A healed step still tests what the original step tested

Tools we may use

Tools are chosen for your stack, not the other way round. Playwright ships planner, generator and healer agents that can be set up for VS Code, Claude Code, Codex or OpenCode, and Microsoft’s Playwright MCP server lets an AI tool drive a browser. CodeceptJS has AI features for healing failing steps and grouping failures. These are named as examples of open-source tools, not partnerships. Zapple.Tech was founded by the founders of CodeceptJS and Codeception, two open-source testing frameworks.

In CodeceptJS, healing needs an AI provider in the configuration, heal recipes (npx codeceptjs generate:heal) and the heal plugin, and it runs when the tests start with the --ai flag. The three steps, as the CodeceptJS documentation shows them:

// codecept.conf.js: the AI provider
import { anthropic } from '@ai-sdk/anthropic'

export default {
  ai: {
    model: anthropic('claude-sonnet-4-6'),
    // or use claude-opus-4-7, claude-haiku-4-5, etc.
  },
}

// the heal plugin
plugins: {
  heal: {
    enabled: true
  }
}

npx codeceptjs run --ai

Snippets from the CodeceptJS documentation (codecept.io/ai). A healed step is still reviewed by an engineer before it is merged.

For the full range of automation work, see QA automation testing services. For browser automation without agents, see web test automation; if the code under test was itself written with AI assistants, see QA for AI-generated code.