# Automation testing trends in 2026: what changed since 2024

> Where test automation stands in 2026: shift-left CI, Playwright, Cypress and Selenium, contract, visual, accessibility and AI testing, and what to adopt now.

- URL: https://computese.com/navigating-the-future-unveiling-10-cutting-edge-automation-testing-trends-of-2024/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-01-01
- Updated: 2026-09-25
- Topics: Custom software, Web development

## In short
- In 2026 the trend is less about new kinds of test than about where each check runs: unit, integration and contract tests on every pull request, browser, visual and accessibility checks on a built app, load tests before release.
- Playwright, Cypress and Selenium are all actively developed. Selenium is moving to the W3C WebDriver BiDi protocol, and Playwright and Cypress both shipped AI test generation in October 2025.
- Automated accessibility checks cover only part of WCAG. Of WCAG 2.2's six new level A and AA criteria, axe-core 4.13 has a rule for one, target size, and it is off by default.
- Flaky tests are the main tax on automation. Use retries to detect and label flakiness, not to hide it, and fix the usual causes: unawaited asynchronous work, concurrency and shared state.
- AI can draft and repair tests, but it cannot decide what correct behaviour is. Gate generated tests with the same review, pipeline and coverage checks as human ones.

Automation testing trends in 2026 are less about new kinds of test than about where each check runs and how far to trust it: fast unit, integration and contract tests on every pull request, browser, visual and accessibility checks on a preview build, load tests with pass/fail thresholds, and AI agents that draft tests a person still reviews.

This page first appeared in January 2024 as a list of that year's trends. This September 2026 rewrite keeps the trend format but checks each trend against what has shipped since: for ten areas of test automation, what changed after 2024, where the limits are, and whether to adopt it now. Versions and dates are as of September 2026.

## Test automation trends at a glance, 2024 to 2026

| Trend                            | What changed since 2024                                                                          | Adopt now?                                               |
| -------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------- |
| Shift-left testing in CI/CD      | It is the baseline; the work is deciding which tests gate a merge                                | Yes: write the gates down                                |
| The test pyramid and its critics | Real databases in throwaway containers make integration-heavy suites affordable                  | Yes, with a shape chosen per system                      |
| End-to-end frameworks            | Playwright and Cypress added AI agents; Selenium is moving to WebDriver BiDi                     | Yes: choose by browsers and languages                    |
| API and contract testing         | OpenAPI 3.2 (September 2025) for schema checks; Pact for consumer-driven contracts               | Yes, where teams deploy independently                    |
| Visual regression testing        | Built into test runners, with accessibility-tree snapshots as a less brittle companion           | Yes, for design systems and key templates                |
| Accessibility automation         | The European Accessibility Act applies since June 2025; most new WCAG 2.2 criteria need a person | Yes, plus manual review                                  |
| Performance and load testing     | INP replaced FID in March 2024; k6 reached 1.0 in May 2025                                       | Yes: budgets per pull request, load tests before release |
| Test data and environments       | Throwaway containers make a fresh database per test run practical                                | Yes                                                      |
| Flaky tests                      | Test runners label flaky tests, isolate retries and lock shared resources                        | Yes: measure, then quarantine                            |
| AI-assisted testing              | Test agents in Playwright and Cypress since October 2025                                         | Pilot it, with human review                              |

The 2024 version also listed hyperautomation, TestOps, low-code, blockchain and geolocation testing. They do not get their own sections here: the first three describe the pipeline and AI practices below under other names, and the last two are specialist needs rather than trends most teams face.

## Shift-left testing: decide what gates every pull request

Shift-left testing means running tests as early as possible: on the developer's machine and on every pull request, while a defect is still one small change away from its cause. Nobody needs convincing in 2026. The useful question is which tests run where.

[Microsoft's DevOps guidance](https://learn.microsoft.com/en-us/devops/develop/shift-left-make-testing-fast-reliable) gives a practical taxonomy. L0 and L1 are unit tests that depend only on the code under test; L2 functional tests may need a database or the file system; L3 tests run against a deployed service; L4 tests run against production. It sets hard budgets for the fast levels: an average under 60 milliseconds per L0 test, under 400 milliseconds per L1 test, and no unit test over 2 seconds. In the case study on the same page, a pull request goes from opening to merge in about 30 minutes, including 60,000 unit tests.

The same page names the opposite move, shift-right: some checks, like its L4 tests, run in production, where real traffic and real configuration live. Most teams need both: fast gates before merge, then synthetic checks and monitoring after release.

Security testing belongs in the same gates. Secret scanning, static analysis and dependency scanning run on every pull request; our [secure coding checklist](https://computese.com/best-practices-for-secure-coding/) covers where each one fits. For dynamic testing, the [ZAP baseline scan](https://www.zaproxy.org/docs/docker/baseline-scan/) spiders a site for one minute by default and only scans passively, without attacks, which is why its authors describe it as suitable for CI/CD pipelines, even against production. ZAP itself changed hands: it [joined forces with Checkmarx](https://www.zaproxy.org/blog/2024-09-24-zap-has-joined-forces-with-checkmarx/) in September 2024 and is now called "ZAP by Checkmarx", still open source under the Apache 2.0 licence.

**Adopt now:** write down what blocks a merge, what blocks a release and how long each stage may take. A pull request check that takes an hour gets bypassed.

## The test pyramid and its critics

The test pyramid says most of your tests should be fast, focused unit tests, with fewer service-level tests above them and only a few tests through the user interface at the top. [Martin Fowler credits](https://martinfowler.com/bliki/TestPyramid.html) Mike Cohn's 2009 book _Succeeding with Agile_ with making it widely known, and states its assumption plainly: broad tests are slower, more brittle and more expensive than focused ones. A suite shaped the other way round, mostly UI tests, is the "ice-cream cone" the pyramid warns against. Fowler also names the exception: if your high-level tests are fast, reliable and cheap to change, you do not need the lower-level ones.

Two alternatives argue for a fatter middle:

- **The testing honeycomb.** [Spotify's engineers](https://engineering.atspotify.com/2018/01/testing-of-microservices) proposed it in 2018 for microservices: mostly integration tests that exercise a service through its API with its real database, a few tests of implementation details, and ideally no integrated tests, meaning tests that pass or fail depending on another system.
- **The testing trophy.** [Kent C. Dodds](https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications) puts static analysis (type checking and linting) at the base, then unit tests, a large integration layer, and end-to-end tests at the top.

[Fowler's 2021 essay on these shapes](https://martinfowler.com/articles/2021-test-shapes.html) makes the point worth keeping: much of the disagreement is about words. What honeycomb advocates call an integration test is often what he calls a sociable unit test, one that uses real collaborators instead of mocks. Ask what a team means by "unit" before arguing about ratios.

What changed after 2024 is the cost of the middle layer. Throwaway databases in containers (see test data, below) make integration tests nearly as easy to run as unit tests. Component testing is being rebuilt as well: Playwright moved its component tests to a stories model in version 1.62, and as of 1.63 its experimental React and Vue component-testing packages [no longer receive updates](https://playwright.dev/docs/release-notes).

**Adopt now:** choose the shape from where your bugs actually come from. Logic-heavy code (pricing, scheduling, parsing) suits the pyramid. A service that mostly moves data between an API and a database suits the honeycomb. A front end suits the trophy.

## End-to-end frameworks: Playwright, Cypress and Selenium in 2026

All three are actively developed. The differences that decide between them are architecture, browsers and languages.

|                         | Playwright                                                                                             | Cypress                                                                              | Selenium                                                   |
| ----------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | ---------------------------------------------------------- |
| Release, September 2026 | 1.63                                                                                                   | 16.1 (September 15, 2026)                                                            | 4.49 (September 9, 2026)                                   |
| Browsers                | Chromium, Firefox and WebKit, also tested against Chrome and Edge                                      | Chrome family and Firefox; WebKit is still an experiment                             | Chrome, Edge, Firefox, Safari and legacy Internet Explorer |
| Languages               | TypeScript, JavaScript, Python, .NET, Java                                                             | JavaScript                                                                           | Java, Python, C#, Ruby, JavaScript, Kotlin                 |
| Changed since 2024      | Aria snapshots (1.49), Test Agents (1.56), Chrome for Testing builds (1.57), bundled MCP server (1.62) | cy.prompt (15.4); HTTP/2 by default in Chromium browsers, Electron deprecated (16.0) | Implementation moving from WebDriver Classic to BiDi       |

Sources: [Playwright release notes](https://playwright.dev/docs/release-notes), the [Cypress changelog](https://docs.cypress.io/app/references/changelog), [Cypress cross-browser guide](https://docs.cypress.io/app/guides/cross-browser-testing) and [experiments list](https://docs.cypress.io/app/references/experiments), [Selenium downloads](https://www.selenium.dev/downloads/) and [supported browsers](https://www.selenium.dev/documentation/webdriver/browsers/).

**Playwright** drives all three browser engines from one API. Before it clicks, it [auto-waits](https://playwright.dev/docs/actionability) until the element is visible, stable, able to receive events and enabled, and fails with a timeout if it never is; its assertions retry the same way. Each test runs in its own [browser context](https://playwright.dev/docs/browser-contexts), and one test can open several contexts to play two users at once, an admin and a customer, or two sides of a chat. Since 1.57 it runs on Chrome for Testing builds rather than plain Chromium.

**Cypress** runs your test code inside the browser, next to the application. Its documentation lists the [permanent trade-offs](https://docs.cypress.io/app/references/trade-offs) that follow: native access to the app, but JavaScript only, one browser at a time (extra tabs need the `@cypress/puppeteer` plugin), and each test bound to one superdomain unless you use `cy.origin`. Cypress 16.0, released September 1, 2026, sends requests over HTTP/2 by default in Chrome, Chromium and Edge, deprecates Electron as a test browser and requires Node.js 22, 24 or 26 and later.

**Selenium** drives browsers through the W3C WebDriver standard and has the widest language support of the three. [Selenium Manager](https://www.selenium.dev/documentation/selenium_manager/), bundled since Selenium 4.6, downloads the right driver (and, when needed, the browser itself) so a browser update no longer leaves a suite with a mismatched driver. The bigger change is underneath the API.

### WebDriver BiDi: the protocol change under the tools

Classic WebDriver is request and response: the test sends a command and the browser answers. [WebDriver BiDi](https://www.selenium.dev/documentation/webdriver/bidi/) adds a WebSocket, so the browser can also push events as they happen: network requests, console messages, JavaScript errors. Until now that capability came from the Chrome DevTools Protocol (CDP), which has no shared public specification. Selenium's documentation describes BiDi as the cross-browser replacement for CDP, calls its own CDP support temporary, and says Selenium is moving its whole implementation from WebDriver Classic to BiDi while keeping backwards compatibility where it can.

In Selenium you switch it on with a browser option:

```python
from selenium import webdriver

options = webdriver.ChromeOptions()
options.enable_bidi = True
driver = webdriver.Chrome(options=options)
```

The standard is still moving. [WebDriver BiDi](https://www.w3.org/TR/webdriver-bidi/) is a W3C Working Draft from the Browser Testing and Tools Working Group, and the latest draft was published on September 24, 2026. Browsers ship it ahead of the final text: Firefox 129 and Puppeteer 23 reached [production-ready BiDi support](https://developer.chrome.com/blog/firefox-support-in-puppeteer-with-webdriver-bidi) in August 2024, when Firefox also deprecated its partial CDP implementation and scheduled it for removal at the end of 2024. [Puppeteer](https://pptr.dev/webdriver-bidi) now uses BiDi by default with Firefox, and still defaults to CDP with Chrome because not every CDP feature has a BiDi equivalent yet.

**Adopt now:** choose by the browsers, languages and multi-user scenarios you need, using the table above, and keep a working suite rather than rewriting it to follow a trend. If your Selenium or Puppeteer code calls CDP directly for network interception or console capture, plan its move to the BiDi APIs now.

## API and contract testing

Most business logic sits behind an API, and testing it there is faster and more precise than through a browser. Playwright can do it in the same suite: its [API testing](https://playwright.dev/docs/api-testing) support sends requests straight to the server, to test the API itself, to prepare server-side state before a browser test, or to check the state after one.

API tests check one service. Contract tests check the agreement between two. [Pact](https://docs.pact.io/) defines contract testing as checking each application in isolation to confirm that the messages it sends or receives match a shared contract. Its approach is consumer-driven: the consumer's tests run against a Pact mock of the provider, and the contract is generated from those tests, request by request. The provider's build then [replays the recorded requests](https://docs.pact.io/getting_started/how_pact_works) against the real provider and compares its responses with the expected ones. Before either side deploys, the broker's [can-i-deploy](https://docs.pact.io/pact_broker/can_i_deploy) check confirms that the version going out was verified against the versions already running in that environment.

![A consumer service's test run produces an orange contract document that is stored in a broker cabinet, and a provider service on the right is checked against a copy of it.](https://computese.com/images/blog/navigating-the-future-unveiling-10-cutting-edge-automation-testing-trends-of-2024/contract.3fef0634c2-1536.webp)

*The contract travels, the services do not: each side is tested alone, and the broker knows which versions are safe together.*

Because the contract holds only what consumers actually use, the provider can change everything else freely. Pact calls this contract by example, as opposed to a schema such as an OpenAPI description, which lists every possible state of a resource. Schema checks are the other half: validating real responses against the provider's OpenAPI description catches drift between the API and its documentation. [OpenAPI 3.2.0](https://spec.openapis.org/oas/v3.2.1.html) was released on September 19, 2025, and the 3.2.1 patch on September 10, 2026.

**Adopt now:** contract tests pay off when several services or teams deploy independently, which is where Pact's own documentation says the technique is most useful. If one team ships a front end and its API together, API tests plus schema validation are often enough.

## Visual regression testing

A visual regression test compares a screenshot of the current build with an approved baseline and fails when they differ by more than a threshold. It catches what functional assertions miss: a stylesheet change that pushes a button off screen, overlapping text, a missing icon.

In Playwright, [`toHaveScreenshot()`](https://playwright.dev/docs/test-snapshots) writes the reference image on the first run and compares against it afterwards with the pixelmatch library. `maxDiffPixels` sets the tolerance, and a `stylePath` stylesheet can hide volatile elements (the documentation's example hides iframes). Its warning is the real cost of the technique: rendering varies with the operating system, browser version, settings, hardware, headless mode and even the power source, so baselines are stored per browser and platform and must be generated in the environment the tests run in. In practice that means one pinned container image, locally and in CI.

![Two browser windows, the approved baseline and the new build, feed a third window where the matching layout is faded grey and only the region of one moved button is marked in orange.](https://computese.com/images/blog/navigating-the-future-unveiling-10-cutting-edge-automation-testing-trends-of-2024/visual-diff.d4633aeef7-1536.webp)

*A pixel diff only shows what changed; a person still decides whether the change is a bug or the new design.*

Since 2024 Playwright added a structural alternative. Aria snapshots, available from version 1.49, compare the page's accessibility tree, written as YAML, instead of its pixels: they fail on a missing heading or a renamed button, not on anti-aliasing. Since 1.62, screenshot baselines can also be stored as lossless WebP instead of PNG.

**Adopt now:** run visual tests on a component library or design system and a handful of key templates, with someone who can approve a baseline change. Screenshotting every page produces diffs nobody reads.

## Accessibility testing automation, and what it cannot catch

Automated accessibility checks are cheap to add and belong in every pull request. The [Playwright documentation](https://playwright.dev/docs/accessibility-testing) lists typical catches: text with poor contrast, form controls without labels a screen reader can announce, and duplicate IDs. It runs the axe engine through the `@axe-core/playwright` package:

```ts
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("checkout has no detectable WCAG A or AA issues", async ({ page }) => {
  await page.goto("/checkout/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});
```

The tools document their own limits. Deque, which maintains [axe-core](https://github.com/dequelabs/axe-core), says the engine finds on average 57% of WCAG issues automatically, and returns elements it cannot decide as "incomplete" for a person to review. The W3C's guidance on [evaluation tools](https://www.w3.org/WAI/test-evaluate/tools/selecting/) is blunter: tools can assist, but they cannot determine whether a site is accessible, and human judgement is required.

WCAG 2.2 widens that gap. It became a W3C Recommendation on October 5, 2023, adding nine success criteria and removing 4.1.1 Parsing; [six of the new criteria](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/) are at level A or AA. In axe-core 4.13, the current release, only one of those six has a rule, target-size, and the [rule list](https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md) says it is disabled by default until WCAG 2.2 is more widely adopted and required. Asking for the `wcag22aa` tag, as in the test above, runs it, because a [tag selection](https://github.com/dequelabs/axe-core/blob/develop/doc/API.md) limits the scan to the rules carrying those tags. What full conformance takes beyond automated checks is covered in our guide to [making a website WCAG compliant](https://computese.com/how-to-make-website-wcag-compliant/).

| New WCAG 2.2 criterion (level)                 | Rule in axe-core 4.13 | How to test it                                                                   |
| ---------------------------------------------- | --------------------- | -------------------------------------------------------------------------------- |
| 2.5.8 Target Size (Minimum) (AA)               | Yes, off by default   | Enable the `wcag22aa` tag; still check custom controls by hand                   |
| 2.4.11 Focus Not Obscured (Minimum) (AA)       | No                    | Tab through each page with sticky headers, chat widgets and banners showing      |
| 2.5.7 Dragging Movements (AA)                  | No                    | List every drag interaction and confirm a single-pointer alternative             |
| 3.2.6 Consistent Help (A)                      | No                    | Check help and contact options keep the same relative order across pages         |
| 3.3.7 Redundant Entry (A)                      | No                    | Walk multi-step forms: earlier answers must be filled in or selectable           |
| 3.3.8 Accessible Authentication (Minimum) (AA) | No                    | Sign in with a password manager and with paste; no puzzle without an alternative |

Focus Not Obscured shows why. The criterion requires that a component receiving keyboard focus is not entirely hidden by content the author added, such as a sticky header or footer. The markup can be flawless and the page still fail, because the failure only exists at a particular scroll position, in a particular layout. You can script part of the check (a Playwright test can press Tab through a page and assert each focused element with `toBeInViewport()`), but whether a sticky bar covers it still takes a screenshot review or a person with a keyboard.

![A keyboard moves focus from link to link up a web page. The last focused link has slipped under the sticky header, its orange focus ring half hidden, while a scanner beside the page shows a check mark.](https://computese.com/images/blog/navigating-the-future-unveiling-10-cutting-edge-automation-testing-trends-of-2024/focus.a5c33c4b14-1536.webp)

*The scan passed and the page still fails: only someone tabbing through it sees focus vanish under the header.*

The stakes rose in 2025. Under [Directive (EU) 2019/882](https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng), the European Accessibility Act, accessibility requirements apply to services such as e-commerce, consumer banking and e-books provided to consumers after June 28, 2025, with an exemption for microenterprises providing services.

**Adopt now:** axe checks on key journeys in every pull request, with the WCAG 2.2 tag on, and a manual keyboard and screen reader pass for each release that changes those journeys.

## Performance and load testing in the pipeline

Performance testing answers two different questions: does each page stay fast for one user, and does the system hold up under many?

For page speed, the targets are Google's [Core Web Vitals](https://web.dev/articles/vitals): Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of page loads. INP [replaced First Input Delay](https://web.dev/blog/inp-cwv-march-12) as the responsiveness metric on March 12, 2024, and that matters for automation: lab tools such as Lighthouse load a page with no user, so they cannot measure INP, and Total Blocking Time is the lab proxy. [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci) puts a Lighthouse report on every pull request, runs Lighthouse several times to reduce variance and enforces budgets on scripts and images. Field data from real visitors stays the final judge.

For load, Grafana k6 turns service-level objectives into [thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/): pass/fail criteria on metrics such as error rate and response time. When a threshold fails, k6 exits with a non-zero code, which fails the CI job:

```js
import http from "k6/http";

export const options = {
  vus: 50,
  duration: "2m",
  thresholds: {
    http_req_failed: ["rate<0.01"], // fewer than 1% of requests fail
    http_req_duration: ["p(95)<300"], // 95% of requests finish within 300 ms
  },
};

export default function () {
  http.get("https://staging.example.com/api/products");
}
```

[k6 reached version 1.0](https://github.com/grafana/k6/releases/tag/v1.0.0) on May 6, 2025, with semantic versioning, at least two years of critical fixes for each major version, and TypeScript test files that run without a build step.

**Adopt now:** Lighthouse CI budgets on key templates in every pull request, a short smoke load test after each deploy to staging, and a full load test before launches and seasonal peaks, against an environment sized like production.

## Test data and test environments

Many slow and unreliable suites trace back to data, not to the test framework. Microsoft's guidance states the rule: functional tests must be isolated, the state must be known when each test starts, and a test that leaves data behind can corrupt the next one.

Three practices make that achievable:

- **Real dependencies, thrown away after each run.** [Testcontainers](https://testcontainers.com/), an open-source library for Java, Go, Python and other languages, starts throwaway instances of databases, message brokers or browsers in Docker for a test and deletes them afterwards, instead of mocks or complicated environment configurations. [GitHub Actions service containers](https://docs.github.com/en/actions/tutorials/use-containerized-services/use-docker-service-containers) do the same at job level: a fresh container for each service, destroyed when the job completes.
- **Isolation inside the browser.** Playwright gives every test its own browser context, with its own cookies and storage. For resources that cannot be isolated, such as one external sandbox account, Playwright 1.63 added test locks: tests that share a lock name never run at the same time, while the rest of the suite stays parallel.
- **Synthetic data, not production copies.** Create the records each test needs through the API or a seed script rather than restoring a production dump. Production copies carry personal data into environments with weaker controls, and they change underneath the tests.

**Adopt now:** yes, all three. They are also the cheapest fix for the next problem.

## Flaky tests: why they happen and how to fix them

A flaky test passes and fails on the same code. [Google measured the cost in 2016](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html): about 1.5% of all its test runs reported a flaky result, almost 16% of its tests showed some flakiness, and about 84% of the pass-to-fail transitions its CI observed involved a flaky test. That last figure is the real damage. When most red builds are noise, people stop believing red builds, and Google notes that developers sometimes dismissed real failures as flaky.

The causes are well studied. In what its authors called the [first extensive study of flaky tests](https://mir.cs.illinois.edu/lamyaa/publications/fse14.pdf) (Luo and colleagues, FSE 2014), the top three causes among 161 classified fixes were asynchronous waits (45%), concurrency (20%) and dependence on test order (12%). All three are about timing and shared state, not about the product.

Current tools attack the largest category directly. Playwright's actions and assertions wait for a condition instead of a fixed delay, which its documentation presents as a way to remove flakiness, and Cypress 16 made its cookie and storage commands retry the way its queries do, part of a release its changelog summarizes as faster tests with less flake.

Retries cut both ways. Playwright [labels a test](https://playwright.dev/docs/test-retries) that fails and then passes on retry as "flaky" rather than "passed", and since 1.62 an isolated retry strategy reruns failures at the end, one at a time, away from the rest of the suite:

```ts
// playwright.config.ts
import { defineConfig } from "@playwright/test";

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  retryStrategy: "isolated", // Playwright 1.62 and later
  use: { trace: "on-first-retry" }, // keep a trace whenever a retry happens
});
```

> [!WARNING]
> A retry that passes hides a failure unless someone reads the flaky count. Report flaky tests separately, quarantine each one with a named owner and a date, and fix the cause. A suite where retries quietly absorb failures will absorb real regressions too.

## AI-assisted testing: what vendors ship and what it cannot replace

Playwright and Cypress both shipped AI test generation in October 2025, and both document exactly what it does.

- **Playwright Test Agents**, added in [Playwright 1.56](https://github.com/microsoft/playwright/releases/tag/v1.56.0), are three agent definitions for your AI coding tool. The [planner](https://playwright.dev/docs/test-agents) explores the app and writes a Markdown test plan; the generator turns the plan into Playwright tests, checking selectors and assertions live; the healer replays a failing test, looks for the changed element, proposes a patch and reruns until the test passes or its guardrails stop it. Playwright also offers an [MCP server](https://github.com/microsoft/playwright-mcp), bundled since 1.62, that lets a model drive a browser through structured accessibility snapshots rather than screenshots.
- **Cypress [cy.prompt](https://docs.cypress.io/api/commands/prompt)**, introduced in Cypress 15.4 and in beta since 15.13 (March 2026), turns test steps written in plain English into Cypress commands. Read its documented limits before planning around it: it needs a Cypress Cloud account or record key, works only for end-to-end tests in Chromium-based browsers, and does not support API requests, iframes or canvas elements.

Meta's report on its own tool is a sobering data point. [TestGen-LLM](https://arxiv.org/abs/2402.09171), presented at FSE 2024, extends existing human-written test suites. In one evaluation, 75% of its test cases built, 57% passed reliably and 25% increased coverage. It was usable because every candidate had to clear those filters before an engineer saw it, and engineers accepted 73% of the recommendations that reached them.

[What AI cannot replace](https://computese.com/the-future-role-of-software-engineers/) is the test oracle: knowing what the software is supposed to do. An agent can see that a button moved; it cannot know whether a refund of the wrong amount is a bug or a new policy. Playwright's own documentation shows the risk: when the healer concludes that the functionality itself is broken, its output is a skipped test. A skipped test inside a green build is how a real regression ships.

> [!IMPORTANT]
> Treat AI-generated and AI-repaired tests like code from a new contributor: review every assertion, run them in the same pipeline, and never let an agent skip or loosen a failing test without a person approving the change.

**Adopt now:** pilot agents for drafting tests from a written plan and for triaging failures. Keep expected results and merge decisions with people.

## Where to start: a test automation plan for 2026

If you are building or rebuilding a suite this year, this order buys the most confidence per hour:

1. Write down the gates for merge, release and deploy, each with a time budget.
2. Run the real database and cache in throwaway containers.
3. Automate the critical journeys in one browser framework, not every screen.
4. Add axe checks with the WCAG 2.2 tag to those journeys, plus a manual keyboard and screen reader pass per release.
5. Add contract tests where teams or services deploy independently.
6. Add visual tests for the design system, in one pinned environment.
7. Set performance budgets per pull request, and load test before launches.
8. Track the flaky rate, and quarantine flaky tests with an owner.
9. Pilot AI test generation on one area, with every generated test reviewed.

If you want this built into a product from its first release, our [custom software development](https://computese.com/services/custom-software-development/) service puts tests, security scans and accessibility checks in the release pipeline, including integration tests against a real database and cache and browser tests on desktop and mobile. For websites and web apps, [web design and development](https://computese.com/services/web-design-development/) runs accessibility checks against WCAG 2.2 AA in every release and visual regression tests on every design system change.

## Key terms
- **Shift-left testing**: Running tests earlier in delivery, on the developer's machine and on every pull request, so a defect is found while the change that caused it is still small. Shift-right is the complement: checks that run in production.
- **Test pyramid**: A model, popularized by Mike Cohn, that puts many fast unit tests at the base, fewer service or integration tests in the middle and a few user interface tests at the top.
- **End-to-end (E2E) test**: A test that drives the whole application the way a user does, usually through a real browser, from the interface down to the database.
- **WebDriver BiDi**: A W3C draft standard that adds a two-way WebSocket connection to WebDriver, so automation can react to browser events such as network requests, console messages and JavaScript errors.
- **Consumer-driven contract test**: A test in which the consumer's tests record the requests it makes and the responses it expects, and the provider is then verified against that recorded contract.
- **Visual regression test**: A test that compares a new screenshot with an approved baseline image and fails when the difference exceeds a set threshold.
- **Flaky test**: A test that both passes and fails on the same code, usually because of timing, concurrency or shared state rather than a change in the product.
- **Load test**: A test that sends many simulated users' requests to a system to see how response times and error rates behave under traffic, judged against thresholds.
- **Test oracle**: Whatever decides whether a test's result is correct: a requirement, an expected value or a person's judgement. Tools can generate test steps; the oracle has to come from someone who knows what the software should do.

## Common questions

### What were the automation testing trends of 2024, and did they last?

This page's 2024 version listed shift-left testing, AI in test automation, visual regression, and performance and security testing, alongside newer labels such as hyperautomation, low-code testing and TestOps. The core four lasted: shift-left is now the baseline, visual checks are built into test runners, performance and security checks run as pipeline gates, and AI arrived as agents inside Playwright and Cypress in October 2025.

### Which is better in 2026, Playwright, Cypress or Selenium?

It depends on the browsers and languages you need. Playwright drives Chromium, Firefox and WebKit from TypeScript, JavaScript, Python, .NET or Java; Cypress runs JavaScript tests inside the browser, one browser at a time, with WebKit still experimental; Selenium has the widest language support and is moving to WebDriver BiDi. If an existing suite works, switching rarely pays for itself.

### How much of accessibility testing can be automated?

Part of it. Deque, which maintains axe-core, says the engine finds on average 57% of WCAG issues automatically, and W3C guidance is that tools can assist but cannot determine accessibility. Of the six new level A and AA criteria in WCAG 2.2, axe-core has a rule for one, target size, and it is off by default.

### Can AI write our automated tests?

It can draft them. Playwright's planner and generator agents turn a written plan into tests, and Cypress's cy.prompt turns plain-English steps into commands. In Meta's FSE 2024 report on TestGen-LLM, 75% of generated tests built, 57% passed reliably and 25% increased coverage, so every generated test still needs review and the same pipeline checks as a human's.

### What causes flaky tests and how do we fix them?

The most common causes are tests that do not wait properly for asynchronous work, concurrency, and tests that depend on run order or shared data. Wait on conditions rather than timers, give each test its own data, use retries only to detect and label flakiness, and quarantine each flaky test with an owner and a date.

### Is shift-left testing still relevant in 2026?

Yes, but it is the baseline rather than a trend. The work now is deciding which tests block a merge, which block a release and which run in production, and keeping pull request checks fast enough that people wait for them instead of working around them.

## Sources
1. [Shift testing left with unit tests](https://learn.microsoft.com/en-us/devops/develop/shift-left-make-testing-fast-reliable), Microsoft Learn
2. [ZAP Baseline Scan](https://www.zaproxy.org/docs/docker/baseline-scan/), ZAP
3. [ZAP Has Joined Forces With Checkmarx](https://www.zaproxy.org/blog/2024-09-24-zap-has-joined-forces-with-checkmarx/), ZAP
4. [Test Pyramid](https://martinfowler.com/bliki/TestPyramid.html), Martin Fowler
5. [Testing of Microservices](https://engineering.atspotify.com/2018/01/testing-of-microservices), Spotify Engineering
6. [The Testing Trophy and Testing Classifications](https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications), Kent C. Dodds
7. [On the Diverse And Fantastical Shapes of Testing](https://martinfowler.com/articles/2021-test-shapes.html), Martin Fowler
8. [Release notes](https://playwright.dev/docs/release-notes), Playwright
9. [Changelog](https://docs.cypress.io/app/references/changelog), Cypress
10. [Downloads](https://www.selenium.dev/downloads/), Selenium
11. [Cross Browser Testing](https://docs.cypress.io/app/guides/cross-browser-testing), Cypress
12. [Experiments](https://docs.cypress.io/app/references/experiments), Cypress
13. [Supported Browsers](https://www.selenium.dev/documentation/webdriver/browsers/), Selenium
14. [Auto-waiting](https://playwright.dev/docs/actionability), Playwright
15. [Isolation](https://playwright.dev/docs/browser-contexts), Playwright
16. [Trade-offs](https://docs.cypress.io/app/references/trade-offs), Cypress
17. [Selenium Manager](https://www.selenium.dev/documentation/selenium_manager/), Selenium
18. [WebDriver BiDi](https://www.selenium.dev/documentation/webdriver/bidi/), Selenium
19. [WebDriver BiDi (W3C Working Draft)](https://www.w3.org/TR/webdriver-bidi/), W3C
20. [Firefox support in Puppeteer with WebDriver BiDi](https://developer.chrome.com/blog/firefox-support-in-puppeteer-with-webdriver-bidi), Chrome for Developers
21. [WebDriver BiDi support](https://pptr.dev/webdriver-bidi), Puppeteer
22. [API testing](https://playwright.dev/docs/api-testing), Playwright
23. [Introduction to Pact](https://docs.pact.io/), Pact
24. [How Pact works](https://docs.pact.io/getting_started/how_pact_works), Pact
25. [Can I Deploy](https://docs.pact.io/pact_broker/can_i_deploy), Pact
26. [OpenAPI Specification v3.2.1](https://spec.openapis.org/oas/v3.2.1.html), OpenAPI Initiative
27. [Visual comparisons](https://playwright.dev/docs/test-snapshots), Playwright
28. [Accessibility testing](https://playwright.dev/docs/accessibility-testing), Playwright
29. [axe-core](https://github.com/dequelabs/axe-core), Deque Systems (GitHub)
30. [Rule Descriptions](https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md), Deque Systems (GitHub)
31. [Axe Javascript Accessibility API](https://github.com/dequelabs/axe-core/blob/develop/doc/API.md), Deque Systems (GitHub)
32. [What's New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/), W3C Web Accessibility Initiative
33. [Selecting Web Accessibility Evaluation Tools](https://www.w3.org/WAI/test-evaluate/tools/selecting/), W3C Web Accessibility Initiative
34. [Directive (EU) 2019/882 on the accessibility requirements for products and services](https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng), EUR-Lex
35. [Web Vitals](https://web.dev/articles/vitals), web.dev
36. [Interaction to Next Paint becomes a Core Web Vital on March 12](https://web.dev/blog/inp-cwv-march-12), web.dev
37. [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci), GoogleChrome (GitHub)
38. [Thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/), Grafana k6
39. [k6 v1.0.0 release notes](https://github.com/grafana/k6/releases/tag/v1.0.0), Grafana k6 (GitHub)
40. [Testcontainers](https://testcontainers.com/), Testcontainers
41. [Using Docker service containers](https://docs.github.com/en/actions/tutorials/use-containerized-services/use-docker-service-containers), GitHub Docs
42. [Flaky Tests at Google and How We Mitigate Them](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html), Google Testing Blog
43. [An Empirical Analysis of Flaky Tests (FSE 2014)](https://mir.cs.illinois.edu/lamyaa/publications/fse14.pdf), University of Illinois Urbana-Champaign
44. [Retries](https://playwright.dev/docs/test-retries), Playwright
45. [Playwright Test Agents](https://playwright.dev/docs/test-agents), Playwright
46. [Playwright v1.56.0 release](https://github.com/microsoft/playwright/releases/tag/v1.56.0), Microsoft (GitHub)
47. [Playwright MCP](https://github.com/microsoft/playwright-mcp), Microsoft (GitHub)
48. [cy.prompt()](https://docs.cypress.io/api/commands/prompt), Cypress
49. [Automated Unit Test Improvement using Large Language Models at Meta (FSE 2024)](https://arxiv.org/abs/2402.09171), arXiv