State of AI in Quality Engineering 2026

The State of AI in Quality Engineering 2026 is TestMu AI's survey of testers, developers and QA leaders, fielded from late July to early October 2026. The short answer: AI now writes much of the code and many of the tests, and most teams still verify that work with a person after the fact, or with another model.

1. 0181% of teams have merged AI-written code or tests they didn't fully understand, according to TestMu AI's State of AI in Quality Engineering 2026 survey; 19% do it regularly.
2. 0244% of teams report more escaped defects or production incidents as AI-generated code grew (TestMu AI, State of AI in Quality Engineering 2026).
3. 0340% of teams say AI writes more than half of their production code, and only 3% say none of it is AI-generated (TestMu AI, State of AI in Quality Engineering 2026).
4. 0441% of teams run any automated check on AI-written code before merge; most rely on a person, or on a QA hand-off after the code is written (TestMu AI, State of AI in Quality Engineering 2026).
5. 0529% of teams that use LLM-as-a-judge regularly merge AI output they don't fully understand, twice the rate of other teams (15%), according to TestMu AI's State of AI in Quality Engineering 2026.
6. 0665% of the time, at the median, AI-generated tests are "almost right, but not quite", and median trust in AI-generated test artifacts is 54 out of 100 (TestMu AI, State of AI in Quality Engineering 2026).
7. 0737% of teams that build AI agents have no systematic way to evaluate them, and only 28% test agents against users who try to break them (TestMu AI, State of AI in Quality Engineering 2026).
8. 0845% of teams building voice or phone agents do not test with background noise or a poor line, and 39% do not test accents, dialects or other languages (TestMu AI, State of AI in Quality Engineering 2026).
9. 0950% of teams spend most of their AI testing budget on generating output (coding-agent seats and model APIs), against 17% on verifying it (TestMu AI, State of AI in Quality Engineering 2026).
10. 1013% of teams have an incident-response plan for AI mistakes (TestMu AI, State of AI in Quality Engineering 2026).

Quoting a figure? Keep its base (for example "of agent builders") and link to this page. Charts can be reused with the credit "Source: TestMu AI, State of AI in Quality Engineering 2026".

Citation

TestMu AI. (2026). State of AI in Quality Engineering 2026. https://www.testmuai.com/research/state-of-ai-in-quality-engineering/

Copy citation

Chart credit

Source: TestMu AI, State of AI in Quality Engineering 2026

Copy chart credit

Three years ago, our Future of Quality Assurance report asked whether teams were ready to use AI in testing. Most were curious and many were cautious: one in five had no plans to use it at all. That question is settled. In this year's survey, 3% of teams have no plans for AI in testing, and 40% say AI writes more than half of their production code.

The question now is who checks the work. AI writes the code, writes the tests for that code, and increasingly grades both. Teams are building AI agents and putting them in front of customers. In most of the teams we surveyed, verification still depends on a person reviewing output after the fact, or on another model.

We renamed this report State of AI in Quality Engineering because that is where the work of quality has moved. The findings come from testers, developers and QA leaders in our community around the world, and we are grateful for their time and candour.

We think anything AI produces should be checked by something other than the AI that produced it, as early as possible and every time it changes. The data in this report suggests most teams are not there yet, and it points to where to start.

Asad KhanCo-founder and CEO, TestMu AI

This is common at every company size. 19% of teams do it regularly and another 33% occasionally. Review does not prevent it: 81% of teams that have a person approve every AI-generated test have still merged AI output they did not fully understand. Letting AI grade AI does not close the gap: teams that use one model to score another do it regularly twice as often (29% against 15%), an association rather than proof of cause.

The checks that do help are automated and run before merge. Where AI-written code reaches a QA team without separate automated tests in CI, 49% of teams see escaped defects (bugs or incidents that reach production) rise, against 38% of teams that run those tests. Developers are the most exposed group: 93% of developers have merged AI output they did not fully understand.

Read chapter 03: who checks the code

Most teams still judge agents by eye: human review is the only evaluation method a majority of agent builders use. Among teams building voice or phone agents, 45% do not test with background noise or a poor line.

Read chapter 05: agents

In 2023 the question was whether AI could be trusted to help with testing. In 2026 AI does much of the work, and the concern is what it exposes.

The comparison below sets the 2023 Future of Quality Assurance report against this survey. Several questions were reworded between editions, so read it as directional unless a line says otherwise.

Four in ten teams say AI generates more than half of their production code. Only 3% say none of it is AI-generated.

Switch the view below to compare how QA practitioners and developers describe the same codebases. QA practitioners put the AI share higher than developers do.

The tools behind that code are coding agents more than autocomplete. Claude Code is the main coding agent for 36% of teams and GitHub Copilot for 26%, followed by Google's Antigravity or Gemini Code Assist (10%) and Cursor (8%). Nearly half of organisations (48%) run AI agents across several stages of the software lifecycle or in orchestrated multi-agent workflows.

Testing has followed. 44% of teams use AI across most testing workflows. More than half have AI generate test code that engineers then edit, and only 21% still write test code by hand with no AI. Most of it runs on general-purpose tools: 47% name chatbot-style LLMs as their main AI tool for testing, against 7% who name a purpose-built AI testing platform.

AI has moved code generation to the developer's desk, but verification has stayed downstream. Only 41% of teams run any automated check on AI-written code before it is merged, either separate tests in CI or the coding agent checking its work in the running app.

We asked how product code written by coding agents is verified before merge. Manual review and a hand-off to QA lead the list. The two automated checks are highlighted below. Some teams use both, so the 41% counts each team once.

For 32% of teams the QA hand-off is the main safeguard, with no separate automated tests in CI. Those teams are more likely to report rising escaped defects: 49%, against 38% of teams that run separate automated tests in CI. Developers lean on lighter checks than QA practitioners: 22% of developers say AI code gets only compile, type or unit checks, against 7% of QA practitioners.

Review of AI-generated tests is common and does not catch everything. 64% of teams have a person approve every AI-generated test before it runs, and 81% of those teams have still merged AI output they did not fully understand.

Testing earlier is not yet a priority. Only 5% of teams name shifting testing earlier as their main focus for AI in testing over the next year, and 48% still place ownership of quality with a separate QA team.

Teams give AI-generated tests, assertions and test data a median trust score of 54 out of 100, and say that output is "almost right, but not quite" a median 65% of the time.

The "almost right" pattern is not unique to this sample. In the 2025 Stack Overflow Developer Survey, 66% of respondents named "AI solutions that are almost right, but not quite" as a frustration. That figure counts how many developers have hit the problem, not how often, so it corroborates the pattern rather than the number (external source: Stack Overflow Developer Survey 2025).

The more a team lets AI check AI, the more it tends to trust the output, and the more often it finds the output almost right. These groups are smaller than the full sample, so read the gaps as directional.

Teams Using LLM-as-a-Judge Merge AI Output They Don't Understand Twice as Often as Others

Using one model to grade another is common: 32% of teams that evaluate AI output use LLM-as-judge. Those teams are more confident in AI and more positive about its return, and they are also more likely to merge AI work they do not understand. They do so regularly twice as often as other teams.

This is an association, not proof of cause: teams that adopt LLM-as-judge may also be the teams moving fastest with AI. Either way, a model's score is a second opinion on the output, not evidence of what the software did.

Handing decisions to an agent shows a similar pattern. Where an agent writes, runs and decides on tests, 24% saw escaped defects rise significantly as AI code grew, against 9% of other teams. That group is small, so read the gap as directional.

Teams Whose Coding Agent Runs Their Application See Rising Defects Half as Often as Others

Teams whose coding agent verifies its own work by running the application are about half as likely to report any rise in escaped defects: 24%, against 47% of other teams. It is a small group, but in this data checking what the software actually does matters more than whether a person or an agent does the checking.

77% of teams build AI agents they need to test, called agent builders in this report, and 72% already have AI features in production. The testing behind those agents is thin.

Text chatbots and virtual assistants are the most common agents (59% of teams), followed by copilots embedded in a product (29%) and voice assistants or IVR phone systems (26%). Among the teams that build them, human review is the only evaluation method a majority use, and 41% also use LLM-as-judge. The chart below combines three questions: how teams evaluate agent output, which real-world conditions they simulate, and which tools they use.

37% of agent builders have no systematic evaluation at all: no regression evals, consistency runs, similarity scoring or evaluation platform. 21% say they use a dedicated agent-testing or eval platform, but when asked to name the tool they use, about two-thirds left the question blank and only 6% named a dedicated evaluation tool such as LangSmith or DeepEval. Among teams building voice or phone agents, 45% do not test with background noise or poor call quality, and 39% do not test accents, dialects or other languages.

Other research points the same way. LangChain's State of Agent Engineering survey (1,340 responses, fielded November to December 2025) found that 29.5% of respondents are not evaluating their agents yet. Its questions differ from ours, so the two figures are not directly comparable (external source: LangChain, State of Agent Engineering).

Teams where AI generates more than half of production code are no more likely to deploy daily or faster than teams with less AI-written code: 29% against 28%.

Reviewing AI Output Now Rivals Flaky Tests as a Drain on QA Time

The main drains on QA time are nearly tied, and the newest one has caught up with the oldest. Developers and QA practitioners feel them differently: flaky tests top the list for QA, environment and test-data setup for developers.

Infrastructure still slows teams down. 27% run automated tests on local machines and 23% start test runs by hand. The volume of AI-written code does not, on its own, predict escaped defects: teams where AI writes more than half of the code report rising defects less often (38%) than teams where AI writes half or less (49%). How the code is checked matters more than how much of it AI wrote.

AI Testing Budgets Favour Generating Over Verifying

Half of teams put more than 15% of their QA budget into AI. Most of that money pays for producing AI output. In the chart, coding-agent seats and model API usage count as generating output; commercial AI testing platforms, eval and observability tooling, and cloud test execution count as verifying it.

Budgets are often loosely tracked: 40% have no separate budget for AI in testing, or do not know it. Most teams still report a return, and the returns are mostly counted in effort. Teams measure ROI by time saved on manual testing (52%), productivity (46%) and faster releases (40%). Far fewer measure it by fewer production incidents (21%) or lower cost of quality (11%).

That gap matters because escaped defects are rising for many of the same teams. 44% of all teams report more escaped defects or production incidents as AI-generated code grew. 16% report a significant decrease, 25% see no noticeable change, and 15% say it is too early to tell or do not measure it. Among teams reporting a positive return, 47% also report rising escaped defects.

Guardrails for Responsible AI in Testing Are Uneven

Data privacy, security or IP exposure is the most common brake on AI in testing (55%). For responsible use, the most common controls are human sign-off (53%) and a written AI policy (45%). Few have planned for an AI mistake: among teams that have seen escaped defects rise, 86% have no AI incident-response plan.

11% say most of their testing already runs autonomously, and another two-thirds expect it to within two years.

Today's pipelines are a long way from that. Only 10% let an agent write, run and decide on tests, and 44% still trigger tests by hand or run scripted CI with no AI. Even among teams that expect most of their testing to run autonomously within a year, or say it already does, the share is still 49%.

The autonomous capabilities deployed so far are mostly about producing and repairing tests: automated test-data generation (39%), self-healing locators (30%) and agent-authored tests in CI (30%). Only 12% use evaluation suites as quality gates in CI. Half of teams (49%) agree that as AI writes more of their code, most QA effort is shifting to validating AI-generated output, and 18% disagree.

Playwright is now the most used test automation framework among teams surveyed, ahead of Selenium.

Most teams run several frameworks side by side: 74% use two or more, the same share as in 2023. A third (33%) use both Playwright and Selenium. Tests run mostly on cloud CI/CD runners such as GitHub Actions (31%) or local machines (27%).

Accessibility testing is uneven. 41% test accessibility both manually and with automation, and 20% do none. Accessibility is also the stage of testing where teams use AI least, with a median depth of 46 on a 0-100 scale.

We asked respondents what would most help their team adopt AI in testing over the next year, and what is missing from today's tools. A third answered in their own words.

The same needs came up again and again. Among those who answered, 40% asked for better integration with the tools and pipelines they already use, 39% for output they can rely on, and 30% for AI that understands their requirements, codebase or domain. One in five asked for better ways to evaluate AI and agents, and 17% raised data privacy or security. Themes were coded by keyword, so treat the shares as a guide.

The findings point to verification as the part of the AI workflow that most needs investment.

Section 11 maps each finding to the part of the TestMu AI platform that addresses it: from findings to fixes.

Each card takes one problem from this report, the survey evidence behind it, and the part of the TestMu AI platform built for it. The common thread is verification that is independent of the AI being checked: an agent can work out how a test runs, while the verdict rests on checks of what the software actually did and on evidence a person can read. Where there is no fixed expected answer, as in a live conversation, an AI evaluator scores against criteria you set, and the transcript is kept for review.

What TestMu AI does not do. It does not replace eval frameworks such as OpenAI Evals, LangSmith or DeepEval, which score model outputs; it tests the behaviour of the apps and agents built on them. It cannot write your AI incident-response plan, though it supplies the evidence that plan will need.

58% of respondents are SDETs, QA leads or testers, and 29% are developers and engineers. They come from the TestMu AI community rather than its customer base.

The sample leans towards organisations based in India and towards SaaS companies, so the figures describe the teams surveyed rather than the whole industry. Every percentage is a share of the people who answered that question, and totals for multi-select questions exceed 100%.

fielded

Online, from late July to early October 2026, through TestMu AI's community channels.

respondents

Testers, test automation engineers, QA leaders, developers, engineering leaders and product managers from the TestMu AI community, at organisations around the world. Respondents are community members, not a sample of TestMu AI customers.

teams

Each response is one person describing their own team. For readability, the report refers to respondents as teams.

sample

Shares are of people who answered each question; bases for subgroups are smaller.

cleaning

Only completed responses were analysed. Duplicate submissions were removed, keeping the most recent, as were test entries and responses completed too quickly to have been read.

published

November 2026. Prepared by TestMu AI's research and marketing team under the TestMu AI editorial policy.

Sources

• TestMu AI, State of AI in Quality Engineering survey, July to October 2026 (all figures unless marked external)
• TestMu AI (then LambdaTest), Future of Quality Assurance survey report, 2023 (comparison in chapter 01)
• External: Stack Overflow, 2025 Developer Survey, AI section (chapter 04)
• External: LangChain, State of Agent Engineering, fielded November to December 2025 (chapter 05)

More definitions are in the TestMu AI software testing glossary.