Automation testing trends in 2026: what changed since 2024

Test automation trends at a glance, 2024 to 2026

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 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 covers where each one fits. For dynamic testing, the ZAP 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 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 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 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 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 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.

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.

Sources: Playwright release notes, the Cypress changelog, Cypress cross-browser guide and experiments list, Selenium downloads and supported browsers.

Playwright drives all three browser engines from one API. Before it clicks, it auto-waits 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, 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 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, 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 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:

from selenium import webdriver

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

The standard is still moving. 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 in August 2024, when Firefox also deprecated its partial CDP implementation and scheduled it for removal at the end of 2024. Puppeteer 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 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 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 against the real provider and compares its responses with the expected ones. Before either side deploys, the broker's can-i-deploy check confirms that the version going out was verified against the versions already running in that environment.

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 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() 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.

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 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:

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, 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 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 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 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 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.

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.

The stakes rose in 2025. Under Directive (EU) 2019/882, 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: 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 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 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: 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:

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 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, 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 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: 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 (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 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:

// 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
});

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, are three agent definitions for your AI coding tool. The planner 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, bundled since 1.62, that lets a model drive a browser through structured accessibility snapshots rather than screenshots.
• Cypress cy.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, 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 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.

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 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 runs accessibility checks against WCAG 2.2 AA in every release and visual regression tests on every design system change.