Regression testing is widely reported but practiced differently across software teams. Available studies place reported use between 53% and 83% in reviewed industrial findings, while a 2009 industrial questionnaire found that 95% of respondents tested before releases but only 10% tested daily. The figures below come from different populations and periods, so they should be read as descriptive observations rather than one pooled industry benchmark.
Contents
- Adoption and reported prevalence
- When teams run regression tests
- Manual and automated testing
- Test selection and suite scope
- Tools and perceived support
- What regression-testing research reaches in practice
Adoption and reported prevalence
Regression testing appears in a substantial majority of the industrial findings summarized by a 2022 literature review. In its Study 1, 72% of respondents reported conducting regression testing. The corresponding figures were 69% in Study 2, 68% in Study 3, 80% in Study 5, 83% in Study 7, 63% in Study 8, and 79% in Study 15. These values are reported as tabulated study results in Industrial Surveys on Software Testing Practices - A Literature Review, rather than as a single contemporary survey.
Across the review’s non-Likert regression-testing findings, reported use ranged from 53% to 83%. The mean and median were both 71%, and the standard deviation was 10 percentage points. The review classified regression testing as the second-most-popular of its five prominent test types by mean use. Because these summary statistics were explicitly descriptive and not weighted for meta-analysis, they do not estimate the share of all software organizations using regression testing.
The cost context is also substantial. An estimate cited in the 2009 industrial survey attributed 80% of testing cost to regression testing. The same estimate said testing represented more than 50% of software-maintenance cost. These are legacy estimates cited in A Qualitative Survey of Regression Testing Practices; they should not be treated as independently verified current cost benchmarks.
| Measure | Reported result | Population or period |
|---|---|---|
| Regression-testing use across reviewed non-Likert findings | 53%–83% | Studies reviewed in 2022 |
| Mean reported use | 71% | Studies reviewed in 2022 |
| Median reported use | 71% | Studies reviewed in 2022 |
| Standard deviation | 10 percentage points | Studies reviewed in 2022 |
| Testing cost attributed to regression testing | 80% | Estimate cited in a 2009 industrial survey |
The spread matters for interpretation. A result near 80% in one study and a result near 60% in another may reflect differences in sector, organization, question wording, or what respondents counted as regression testing. The available evidence supports high reported prevalence, but not a universal operating model.
When teams run regression tests
Release timing dominates daily execution in the industrial questionnaire. In that 2009 survey, 95% of respondents said they regression tested before releases. Only 10% said they regression tested daily. This gap describes a release-oriented practice: regression testing was common at a major delivery checkpoint, while continuous or daily execution was much less common.
The 2020 Android practitioner survey gives a more detailed view of maintenance and update events. Among Android practitioners, 51% said it was always necessary to retest after maintenance or an update. Another 20% said they sometimes tested after maintenance or an update, 19% said they often tested, 6% said they rarely tested, and 4% said they never tested. These responses come from a specific mobile-app population and should not be generalized to every software product.
Taken together, the two surveys distinguish two questions: whether regression testing is part of delivery, and whether it is triggered consistently after change. The 2009 release figure shows strong adoption around releases. The Android responses show that post-update retesting was not uniform: the largest single group selected “always,” but the remaining responses described practices ranging from sometimes to never. Measurement dates and geography are not supplied in the source summary, so those dimensions should remain unspecified.
Manual and automated testing
The industrial questionnaire reported a split rather than an automation-dominated pattern. Half of respondents reported an equal amount of manual and automated regression testing. A further 30% reported performing regression testing exclusively manually. The supplied result does not provide a complementary percentage for every other automation mix, so it should not be used to calculate an automation share.
Android practitioners reported a similarly mixed set of approaches in 2020. Fifty-two percent said they mainly adopted both manual and automated testing. Thirty percent said they performed only manual testing, and 18% said they followed a tool-supported testing process. In the same survey, 35% said they used no tools to test their apps. “Tool-supported testing process” and “using tools” are not necessarily identical response categories, so these percentages should be kept separate.
These findings suggest that automation is present without replacing manual work. A team can combine automated checks with exploratory or scenario-based manual testing, while another may rely entirely on manual execution. The survey results do not report execution volume, pass rates, maintenance time, or the relative effectiveness of the approaches. They therefore describe reported practice, not comparative quality or productivity.
Test selection and suite scope
Selection practices reveal how teams manage the size and cost of regression suites. Only 10% of industrial-survey respondents used ad-hoc regression-test selection. At the same time, 70% confirmed focusing regression testing on functional test cases, and 50% confirmed using smoke tests in regression testing. These results come from the 2009 questionnaire reported in A Qualitative Survey of Regression Testing Practices.
The Android survey reported several overlapping selection and reuse behaviors. Seventy-seven percent selected and reused test cases referring to changes between app versions. Fifty-nine percent re-executed all test cases from the original app version. Fifty-eight percent analyzed whether new test cases were needed for the updated app. Ten percent excluded test cases they considered non-fault-finding for the updated app. Since respondents could report multiple practices, these figures should not be added together.
The contrast between change-focused selection and full-suite re-execution is important. A team may prioritize changed areas while also retaining a broad original suite. The 59% full-reexecution result does not prove that those teams ran every test in every release; it reports that respondents re-executed all test cases from the original app version within the survey’s described practice. Likewise, the 77% change-oriented result does not establish how many tests were selected or how often they were run.
Tools and perceived support
Tool use was limited in the 2020 Android practitioner survey. Sixty-seven percent used no particular tools for regression testing. Thirteen percent used the same tools for regression tests as for regular tests, 12% used particular regression-testing tools identified in the literature, and 4% used other tools such as TestNG or in-house tools. The categories sum to the reported distribution, but they represent a survey population of Android practitioners rather than the software industry as a whole.
Perceived adequacy was also uneven. Ten percent said existing regression-testing tools never met their needs, 8% said they barely met their needs, and 13% said they sometimes met their needs. Twenty-four percent said the tools often met their needs, while 18% said they always met their needs. The survey summary does not state how the remaining responses were categorized, so these values should not be converted into a complete satisfaction rate.
The tool results point to two different constraints. Some practitioners reported no particular regression-testing tool at all, while others had tools that did not consistently meet their needs. The data does not identify which product features caused dissatisfaction, and it does not support ranking tools by effectiveness. It does, however, show why adoption percentages and perceived support should be analyzed separately.
What regression-testing research reaches in practice
The 2023 State of Practical Applicability of Regression Testing Research: A Live Systematic Literature Review examined 79 papers covering studies from 2016–2022. Seventy-four papers had industrial motivation for a regression-testing approach, 50 included experiments on industrial or industrial-scale software, and 36 had an industrial author. Yet only 16 included practitioner feedback, 26 had an available regression-testing tool, and 20 reported techniques put into practice.
Follow-up results show that reported implementation was not always durable. Of 16 papers initially reporting partner implementation or ongoing implementation, six were confirmed still in use. Four authors said the technique had fallen out of use, while eight authors reported implementing their approach after publication. Among the 20 papers with techniques used in practice, 14 had at least one industry-affiliated author, but only eight included feedback from the practitioners who used them.
The review also found a gap between research attention and implementation. It identified 16 machine-learning regression-testing papers, but only three had been implemented in practice. Only eight of the 79 reviewed papers addressed test-suite reduction, and one addressed test-suite augmentation. Those counts describe the reviewed research set; they do not measure the total global research literature.
Practitioner challenges were direct. Sixty percent of surveyed practitioners called creating or updating regression tests a major real-world challenge, and 47% cited refactoring or removing obsolete regression tests as a pain point. In the CNR practitioner survey, 60% said they did not know about regression-testing tools originating from research, while 35% said they used or had used a tool to aid regression testing. The findings indicate that practical applicability depends not only on a technique’s experimental result, but also on maintenance effort, awareness, tool availability, and continued use.
The evidence therefore supports a measured interpretation of regression-testing statistics. Reported adoption is high in several surveys, release-based execution is much more common than daily execution in the cited industrial questionnaire, and manual and automated methods coexist. At the research boundary, industrial motivation is common, but practitioner feedback, available tools, and sustained implementation are less common. These are distinct measurements from distinct populations and periods, not a single forecast of future practice.