Software Testing Statistics: 40+ Data Points on Quality, Automation, and Bugs

Testing is not a cost center in the way most companies think it is. Bad software is the cost center. Testing is one of the few things standing between your team and that bill.

• Poor software quality cost the U.S. economy at least $2.41 trillion in 2022. That estimate comes from the Consortium for Information & Software Quality's 2022 report. (CISQ, 2022)
• CISQ estimated $1.52 trillion in accumulated technical debt in the U.S. in 2022. That debt does not stay theoretical. It shows up as defects, rework, late releases, and fragile systems. (CISQ, 2022)
• Software supply chain problems contributed an estimated $2.41 trillion in poor-quality cost categories when combined with operational failures, unsuccessful projects, and legacy system issues. The report makes the bigger point that software quality failures are now an economic problem, not just an engineering problem. (CISQ, 2022)
• Tricentis' Software Fail Watch reported 606 public software failures in 2017. Those failures affected more than 3.6 billion people and were connected to $1.7 trillion in lost revenue. (Tricentis Software Fail Watch, 2018)
• In that same Tricentis analysis, 331 failures were attributed to software bugs. Bugs were the largest single failure category. (Tricentis via TechRepublic, 2018)
• Tricentis' 2024 mobile application quality research surveyed more than 1,000 senior IT professionals and developers across the U.S., Germany, Singapore, and the U.K. The company found businesses estimating poor mobile app quality costs up to $2.49 million in lost revenue. (Tricentis, 2024)

That is the part developers need to get good at explaining. Testing is not about being slow or cautious for its own sake. It is about avoiding the much slower path where defects escape, customers complain, support gets buried, engineers context-switch into fire drills, and leadership suddenly asks why nobody saw it coming.

You did see it coming. You just did not have the time, coverage, environment, data, or release process to catch it.

Coverage numbers can lie if teams treat them like trophies, but low coverage usually tells the truth: the team is guessing.

• Mabl's 2024 State of Testing in DevOps survey found 67% of both mobile and web app teams had 60% or less test coverage. (mabl, 2024)
• One in five teams in that same mabl research had less than 20% test coverage. That is not a safety net. That is a prayer. (mabl, 2024)
• For mobile teams, roughly 48% of defects were found in the deployment stage. In other words, almost half were discovered right before the feature was supposed to ship. (mabl, 2024)
• 73% of mobile app development teams had less than 60% non-functional test coverage. Performance, accessibility, reliability, and usability often get tested too late or not deeply enough. (mabl, 2024)
• About one in four mobile teams had less than 20% non-functional test coverage. That is a serious risk when users judge mobile apps on speed, stability, battery behavior, and device compatibility. (mabl, 2024)
• Android has more than 24,000 distinct device types and 14 major OS versions to consider. Mabl cited this as one reason mobile testing gets so hard at scale. (mabl, 2024)
• Apple's iPhone ecosystem still includes more than 30 iPhone types and 17 possible operating systems in the same testing challenge. Even the “simpler” mobile platform is not simple. (mabl, 2024)

Here is the blunt version: if your test coverage is low and your release cadence is high, your users are part of the QA process. You may not say that in the roadmap meeting, but that is what the system is doing.

Good coverage does not mean every line has a shallow assertion wrapped around it. It means the important behavior is protected. The critical flows are exercised. The riskiest failure modes are watched. The team can change code without holding its breath.

That confidence is what lets good developers move fast. Not the absence of testing. The presence of trustworthy testing.

Automation is not magic. Bad automated tests are just expensive noise. But when automation is aimed at the right problems, it gives developers something manual testing cannot: fast, repeatable feedback.

• The software testing market passed $45 billion in market size. Market research cited by Global App Testing points to testing as a large and growing software discipline. (Global Market Insights via Global App Testing, 2025)
• The software testing market was projected to grow at about a 5% compound annual growth rate from 2023 to 2027. (Global Market Insights via Global App Testing, 2025)
• The global software testing market has been projected to reach $109.5 billion by 2027. (GlobeNewswire market research cited by Global App Testing, 2025)
• Automation testing has been forecast to reach roughly $68 billion by 2025. (RWS market research cited by Global App Testing, 2025)
• In 2020, 44% of IT organizations automated 50% or more of their testing. (RWS cited by Global App Testing, 2025)
• Only 5% of companies were reported as doing fully automated testing. Most organizations still use a mix of manual and automated work. (ERP Today cited by Global App Testing, 2025)
• About two-thirds of software development companies use either a 75:25 manual-to-automation ratio or a 50:50 ratio. That means hybrid testing is the normal state for most teams. (ERP Today cited by Global App Testing, 2025)
• Only 9% of surveyed respondents exclusively performed manual testing. Purely manual QA is becoming less common as release cycles speed up. (ERP Today cited by Global App Testing, 2025)
• 24% of companies that invested in test automation reported immediate ROI. Another 24% reported positive ROI within six months, and 28% within a year. (Global App Testing summary, 2025)
• Only 9% of respondents in that automation ROI data reported unsuccessful outcomes. (Global App Testing summary, 2025)

The lesson is not “automate everything.” That is lazy thinking. The lesson is to automate the checks that humans should not be repeating. Regression paths. Build verification. API contracts. Security checks. Critical customer flows. The stuff that needs to run every day, not whenever someone remembers.

Manual testing still matters. Exploratory testing still matters. Human judgment still matters. But if your team is manually repeating the same login, checkout, deployment, and smoke-test scripts every release, you are not being careful. You are wasting humans on work the machine should be doing.

Modern software teams do not get to treat testing as a phase at the end. CI/CD turns testing into a constant signal. If that signal is weak, slow, or noisy, the whole delivery system suffers.

• Mabl's 2024 research found DevOps transformation was still being prioritized by 89% of companies. (mabl, 2024)
• Technology limitations became the most common DevOps obstacle in mabl's 2024 survey. Among fully DevOps teams, 40% said technology was holding them back. (mabl, 2024)
• One in three aspiring DevOps teams reported budget as their biggest obstacle. (mabl, 2024)
• Two-thirds of fully DevOps organizations used commercial test automation tools for QA. Only 40% of aspiring DevOps teams did the same. (mabl, 2024)
• 26% of fully DevOps teams used five or more testing tools. (mabl, 2024)
• 41% of teams planned to purchase new testing tools. That suggests quality engineering stacks are still expanding. (mabl, 2024)
• PractiTest's 2024 State of Testing report found just under 50% of testers were involved in defining and maintaining CI/CD processes. (PractiTest, 2024)
• Only 10% of PractiTest respondents said their organization did not deploy CI/CD. (PractiTest, 2024)

This is where a lot of teams get stuck. They adopt the ceremony of DevOps without building the quality system underneath it. They deploy more often, but the tests are flaky. They merge faster, but the coverage is thin. They buy tools, but the signals are scattered across dashboards nobody trusts.

Good CI/CD is not just a pipeline. It is a promise: if this thing is green, we have a reasonable basis to move forward. If your team does not believe that promise, the pipeline is theater.

Flaky tests are poisonous because they damage the one thing a test suite must protect: trust.

• Google reported that almost 16% of its tests showed some level of flakiness. (Google Testing Blog, 2016)
• Google also reported that when a test changed from passing to failing in post-submit CI, 84% of the time it was a flaky test rather than a real regression. (Google Testing Blog, 2016, widely cited in later testing research)
• Google engineers estimated losing about 20 minutes per duplicate bug caused by intermittent failures. (Google Testing Blog, 2016)
• A developer survey on test flakiness found 91% of respondents experienced flaky tests at least a few times per year. (Eck et al. and related flakiness survey literature, 2022)
• Among developers who experienced flaky tests at least a few times per year, 79% rated the issue as moderate or serious. (A Survey on How Test Flakiness Affects Developers, 2022)
• Scientific studies cited in flaky-test research have found roughly 0.5% to 1% of tests to be flaky in studied systems. That sounds small until you run thousands of tests many times per day. (A Survey on How Test Flakiness Affects Developers, 2022)
• A large-scale longitudinal flaky-test study found 184 of 245 newly observed flaky tests, or 75%, were already flaky when first added to a project. (Bell et al., OOPSLA, 2020)
• Microsoft Research found that a tool approach for certain flaky tests could reduce running times by up to 78% without empirically changing the frequency of flaky failures. (Microsoft Research, 2020)

The worst part of a flaky test is not the failed build. It is what happens after the team learns to ignore failed builds. Once developers start saying “rerun it” as a reflex, the test suite has lost authority.

That is dangerous because the next red build might be real. But the team has been trained by noise to treat red as maybe. Maybe is where production bugs sneak through.

The fix is not to delete every flaky test and pretend the system is clean. Some end-to-end tests catch real integration risks precisely because they exercise messy conditions. But flaky tests need ownership, quarantine rules, retry policy, signal tracking, and a path back to trust. Otherwise your CI becomes a slot machine with YAML.

AI is now part of the testing conversation whether teams are ready or not. It can help generate tests, summarize failures, create test data, and inspect behavior. It can also generate false confidence at machine speed.

• Mabl's 2024 report found four in five teams had started incorporating AI into their development processes. (mabl, 2024)
• 60% of development and QA teams had somewhat or fully embraced AI. Among fully DevOps teams, that rose to 76%. (mabl, 2024)
• Capgemini and OpenText's World Quality Report 2024-25 identified GenAI and test automation as leading responses to modern quality challenges. (World Quality Report, 2024-25)
• The World Quality Report recommended an enterprise-wide QA automation strategy to improve consistency and cost efficiency. (World Quality Report, 2024-25)
• PractiTest's 2024 report said many testers still were not using AI testing tools, even while recognizing their potential for efficiency and complex test handling. (PractiTest, 2024)
• GitLab's 2026 Global DevSecOps Survey included 3,266 DevSecOps professionals and focused heavily on AI's impact on software delivery and security. (GitLab, 2026)

AI will almost certainly make testing faster. The real question is whether it makes testing better.

There is a big difference. Faster generation of shallow tests does not help much. Faster triage of flaky failures, better test data, smarter regression selection, clearer failure summaries, and stronger coverage of edge cases can help a lot. The teams that win with AI testing will not be the ones that blindly generate the most test cases. They will be the ones that use AI to shorten feedback loops while keeping human ownership of quality.

One of the strangest things about software quality is that companies will measure everything except the cost of the defects they keep shipping.

• PractiTest's 2024 State of Testing report found 50% of organizations do not measure the cost of defects escaping into production. (PractiTest, 2024)
• PractiTest reported TDD adoption rose to 23% of survey participants in 2024, up from 18% the prior year. (PractiTest, 2024)
• The same PractiTest report is in its 11th year, which gives the survey long-running visibility into testing trends. (PractiTest, 2024)
• Global App Testing's statistics summary cited QA as representing around 40% of development budget in some industry estimates. (Testlio cited by Global App Testing, 2025)
• 52% of IT teams in the same summary credited rising QA budgets to the growing number of releases. Faster release cycles create more test cycles. (Testlio cited by Global App Testing, 2025)
• The global software tester ratio was estimated at 5.2 testers per 100,000 people, with Ireland at 61.2 per 100,000 and the U.S. and Canada at 37.1 per 100,000. (Global App Testing, 2025)

Metrics do not make software better by themselves. Plenty of teams track coverage and still ship garbage. But not measuring escaped defects is like running a restaurant and refusing to track food poisoning complaints because the spreadsheet would be awkward.

If you want a grown-up quality process, start with a few measurements that actually change behavior: escaped defects, flaky-test rate, time to diagnose failures, test runtime, critical-flow coverage, defect age, and how often the team bypasses the pipeline. Those numbers are not perfect. They are much better than arguing from vibes.

There are a few obvious conclusions once you line up the data.

1. Poor quality is wildly expensive. CISQ's $2.41 trillion estimate should permanently kill the idea that quality is a small internal engineering preference.
2. Most teams are under-covered. When 67% of mobile and web teams sit at 60% test coverage or less, the average team is carrying more release risk than it admits.
3. Automation is necessary, but not sufficient. The market is growing, ROI can be real, and fully manual testing is fading, but automation only helps when the tests are reliable and aimed at meaningful risk.
4. Flaky tests are not harmless. They train developers to distrust CI. Once that happens, real failures get ignored.
5. AI will raise the stakes. Teams will create tests faster, code faster, and ship faster. Without strong quality judgment, they will also create noise faster.

If you are an individual developer, stop treating testing like something that belongs to another department. Your code is not done when it compiles. It is not done when it works once on your machine. It is done when the important behavior is protected well enough that the next developer can change it without fear.

If you are a team lead or engineering manager, stop asking whether you can “afford” better testing. You are already paying for quality. The only question is whether you pay up front through disciplined engineering or later through support tickets, incident calls, rollback meetings, customer churn, and developers quietly losing faith in the codebase.

The rockstar move is not writing clever code. It is building systems that keep working after clever people touch them.

There is also a career lesson here. Developers who understand testing are easier to trust with bigger work. They can explain risk, design code that is easier to verify, and push back on reckless timelines without sounding like they are hiding behind process. That is rare. A lot of programmers can write code that passes the happy path. Fewer can build code that survives bad inputs, weird timing, old data, slow networks, partial outages, and the next person changing one line six months from now.

So when you read these statistics, do not file them under QA trivia. File them under professional advantage. Testing is one of the places where average developers and serious engineers separate.

This article synthesizes software testing statistics from primary reports, research summaries, and reputable industry publications available as of May 2026. Key sources include:

• Consortium for Information & Software Quality, Cost of Poor Software Quality in the U.S.: 2022 Report - economic cost of poor software quality and technical debt.
• Tricentis Software Fail Watch and Tricentis 2024 mobile application quality research - public software failures, affected users, lost revenue, and mobile quality costs.
• Mabl, 2024 State of Testing in DevOps Report - test coverage, DevOps maturity, QA tooling, AI adoption, and mobile testing challenges.
• PractiTest, 2024 State of Testing Report - TDD adoption, CI/CD involvement, defect-cost measurement, AI testing adoption, and testing trends.
• Capgemini and OpenText, World Quality Report 2024-25 - enterprise QA automation strategy, GenAI, and quality engineering trends.
• Google Testing Blog, Flaky Tests at Google and How We Mitigate Them - flaky-test costs and mitigation practices.
• A Survey on How Test Flakiness Affects Developers and What Support They Need To Address It - prevalence and perceived severity of flaky tests among developers.
• Bell et al., A Large-Scale Longitudinal Study of Flaky Tests - lifecycle data on flaky tests in open-source projects.
• Microsoft Research, A Study on the Lifecycle of Flaky Tests - flaky-test runtime reduction research.
• GitLab Global DevSecOps Survey - DevSecOps and AI adoption context from 3,266 professionals.
• Global App Testing software testing statistics summary - testing market size, automation adoption, QA budget, tester ratios, and automation ROI, with underlying market sources cited in the article.

Some market-size and automation figures are cited through reputable summaries that point to underlying market research providers. The article avoids anonymous claims where possible and uses exact figures only when they were attributable to a named report, study, or publication. Numbers were selected for practical usefulness to developers, engineering managers, QA leaders, and teams making quality investment decisions.