Software development is accelerating. AI-assisted coding, increasingly autonomous workflows and faster release cycles are changing how much software organisations can build and how quickly they can bring it into production. But the 2026 Quality Transformation Report: Operationalizing quality and trust in the era of agentic software delivery suggests that software quality is not advancing at quite the same pace.
Based on a survey of 2,501 senior IT decision-makers, investors and QA and DevOps professionals across six countries, the report highlights a growing gap between the speed at which software can now be produced and organisations' ability to validate it with confidence.
One finding stands out immediately: 60% of organisations regularly ship untested code into production. That figure has barely changed from 63% the previous year. The rate reaches 68% in Germany and 66% in both Ireland and Japan, while even the lowest figure among the surveyed markets, the UK, sits at 49%.
The issue is not simply that organisations need to test more. The report points towards a more fundamental challenge: as development capacity grows, organisations need better ways to determine what needs to be tested, where the greatest risks are and what should be prioritised before release.
Too much software, not enough time to test it
The reasons organisations give for releasing untested software are particularly revealing. In the previous year's research, respondents were more likely to attribute untested releases to accidental quality slips. In 2026, the trade-off is more deliberate. 32% say untested code reaches production because of top-down pressure to accelerate delivery, while 30% say there is simply too much code to test.
At the same time, AI is increasing development capacity considerably. 68% of organisations have already implemented AI in some or all of their development and delivery workflows, and 36% identify implementing AI agents within the software development lifecycle as a top IT priority. Organisations are already seeing measurable benefits: 37% report improved quality and risk detection, 36% improved accuracy and consistency, and 32% improved test automation coverage.
The challenge is therefore not AI adoption itself. It is what happens when software can be created and changed faster than existing quality processes can reasonably validate it. More code means more possible behaviours, more changes to assess and potentially more tests to create, execute and maintain. Trying to respond simply by increasing the volume of testing risks turning quality assurance into a race it cannot sustainably win.
The more useful question is not necessarily how to test everything. It is how to identify what matters most.
Test coverage is not the same as risk coverage
One of the most significant findings in the report is that only 37% of organisations are very confident that their testing strategy addresses the most critical risks to software quality and business performance.
That distinction matters because test volume and risk coverage are not interchangeable. An organisation can have thousands of test cases, high automation rates and consistently successful test executions while still leaving important business risks insufficiently validated. A large test suite tells us how much testing is taking place. It does not necessarily tell us whether the scenarios with the greatest potential impact have received the appropriate level of attention.
Consider a payment application. A cosmetic defect on a secondary screen and a failure that allows a transaction to be processed twice are both software defects, but their consequences are very different. Measuring them equally because both correspond to a test case provides little insight into the actual release risk.
This is where risk-based testing becomes increasingly important. Rather than attempting to give every feature and scenario the same level of attention, teams assess potential failures according to factors such as likelihood and business impact. Testing effort can then be directed towards the areas where a failure would matter most.
As AI increases the volume and pace of software development, that prioritisation becomes less of an optimisation and more of an operational necessity.
Poor software quality has measurable business consequences
The report also makes clear why this prioritisation should extend beyond QA teams. Organisations identify security breaches and compliance failures (30%), technical debt and rework costs (28%), and loss of customer or partner trust (25%) among the leading business impacts of poor-quality software. One in five organisations reports that poor software quality costs the business as much as $5 million annually.
Almost half of organisations report annual losses between $500,000 and $1 million as a result of poor software quality and associated effects such as technical debt and increased maintenance costs. The financial exposure increases with organisational scale: 40% of enterprises with more than 1,000 employees report annual costs between $1 million and $5 million.
These figures reinforce an important change in how software quality needs to be considered. Testing decisions are not only technical decisions. When a software failure can affect revenue, compliance, operational continuity or customer trust, deciding what needs to be validated before release becomes a business-risk decision as well.
Financial services reports the highest rate of untested releases
This is particularly relevant in regulated and operationally critical industries. 64% of financial services organisations surveyed report shipping untested code into production, the highest percentage among the industries included in the report. Retail follows at 63%, while energy and utilities sits at 58%. More than half of organisations in every major industry surveyed report releasing untested code.
In financial services, the consequences of software failure can extend well beyond a poor user experience. Applications support payments, account access, customer data, regulatory processes and other business-critical workflows. A defect affecting one of those processes carries a very different level of risk from an issue affecting a non-critical interface element.
This makes prioritisation essential. If an organisation cannot realistically test every possible behaviour to the same depth before every release, it needs a systematic way to identify where failures are most likely, where their consequences would be greatest and which scenarios therefore require the strongest test coverage.
Risk-based testing provides a framework for making those decisions explicit rather than relying on test volume as a proxy for quality.
Leadership and QA do not see the same level of risk
The report also identifies a notable difference between how executives and practitioners perceive testing readiness. 93% of CEOs, CIOs and CTOs believe their testing strategies address the most critical risks to software quality and business performance. Among QA and DevOps professionals, confidence falls to 70%.
A similar gap exists around AI. 81% of CEOs report high trust in the AI-driven systems, data and automation tools informing software delivery decisions, compared with 56% of QA and DevOps practitioners. Leadership is also considerably more confident about organisations' ability to operationalise and govern AI agents: 44% report being very prepared, compared with 23% of practitioners.
There is even disagreement about the disagreement. While 42% of C-level leaders believe software developers and executives are fully aligned on code quality and delivery readiness, only 22% of QA and DevOps leaders share that view.
This matters because traditional quality metrics can make software readiness appear more straightforward than it really is. Pass rates, test counts and automation percentages are useful operational measures, but they need context. A release with a 98% pass rate may look reassuring, yet that number says very little about the release risk unless the organisation understands what the remaining failures or untested areas actually represent.
A clearer view of risk can help create a common language between the teams building and testing software and the leaders responsible for deciding whether the resulting level of risk is acceptable.
AI can support quality, but more automation alone is not enough
The report does not present AI as purely a source of additional complexity. Organisations that have already implemented it are reporting improvements in quality and risk detection, accuracy and consistency, and test automation coverage.
The question is how those capabilities are applied.
Using AI to generate more tests can certainly reduce manual effort. But if AI-generated development results in considerably more software while AI-generated testing simply results in considerably more test cases, organisations may still be left with the same underlying problem: a growing volume of information without a clear understanding of what matters most.
A more valuable application is to use AI earlier in the quality process. Requirements, specifications and user stories contain information about expected behaviour, business rules and potential failure scenarios. Analysing those inputs can help teams identify risks before deciding which tests should exist at all.
The sequence then becomes more deliberate: understand the software, identify potential failures, assess their likelihood and impact, prioritise the risks and create tests around the areas that require the greatest confidence.
That shifts AI's role from simply producing more testing assets to helping teams make better testing decisions.
Tool sprawl is creating another quality challenge
More tooling does not automatically solve the problem either. 53% of organisations now manage between six and ten AI or automation tools across the software development lifecycle, and 33% say this growing tool sprawl is creating operational complexity that makes continuous software quality harder to achieve at scale. Another 28% say code volume is increasing faster than development teams can realistically manage.
Trust in autonomous decision-making is also becoming more cautious as organisations gain practical experience with the technology. High confidence in AI agents making release-impacting decisions has fallen from 48% in 2025 to 34% in 2026. Although 82% of organisations feel at least somewhat prepared to govern AI agents and autonomous workflows, only 35% feel fully prepared to manage those environments at scale.
These figures suggest that the next stage of quality engineering will require more than simply introducing additional AI tools into existing workflows. Organisations need visibility into risk, clear governance and enough evidence to understand why a release should or should not be trusted.
From testing more to testing what matters
The 2026 Quality Transformation Report captures a software industry in an unusual position. Development capacity is expanding rapidly, yet 60% of organisations still regularly release untested code. Thirty percent say they simply have too much code to test, while only 37% are very confident that their testing strategy covers the risks most critical to software quality and business performance.
Increasing test volume alone is unlikely to close that gap. As AI makes it possible to create more software, quality strategies need to become more selective about where testing effort is applied and more explicit about the business risks behind those decisions.
The objective should not be to treat every possible test with equal importance. It should be to understand where software can fail, what those failures would mean for the organisation and whether the most significant risks have been adequately tested before a release reaches production.
In an environment where testing everything is becoming increasingly unrealistic, knowing what matters becomes part of quality itself.
See your software risks before deciding what to test
This is exactly the problem we built the QA Risk Agent to address.
Instead of starting with a blank test suite, the QA Risk Agent starts with the software specifications you already have. Upload your documentation and it identifies potential risks, evaluates them based on their likelihood and potential impact, and creates a prioritised view of where your testing effort should go. From there, those risks can be turned into targeted test cases.
The goal is straightforward: before creating more tests, understand what actually needs to be tested.
With development moving faster and the amount of software requiring validation continuing to grow, that distinction matters more than ever.
