Unit testing is part of a broader software-quality movement toward earlier, automated feedback. Survey results from GitLab, SmartBear, and Tricentis show growing developer participation and automation, but they also show that testing remains a major source of delivery delay. The figures below are descriptive survey and project-sample statistics, not universal benchmarks. Several measure software testing or automation broadly rather than unit tests alone.
Table of contents
- Adoption and role in software quality
- Automation maturity and coverage
- Shift-left development and TDD
- Team structure and quality workflow
- Testing delays and release decisions
- CI/CD, serverless projects, and execution patterns
Adoption and role in software quality
The available adoption measures suggest that developer-level testing was becoming more common, although it was not yet universal. In GitLab’s 2020 DevSecOps survey, 31% of respondents said developers tested some of their code. That category includes developer-level unit testing, but it is not a unit-test-only measure. The same survey found that 25% said automated testing happened as code was being written, the stage where unit tests commonly run. About 9% said their organizations practiced test-driven development (TDD), a unit-test-first approach. These figures come from the 2020 report, Testers and DevSecOps, and should be read as survey responses rather than a census of development teams.
GitLab’s 2021 survey summary reported modestly higher developer participation. Roughly 34% of respondents said developers tested some of their own code, compared with 31% in 2020. In the same comparison, 32% said automated testing happened as code was written, up from 25% in 2020. The figures are reported in The software testing life cycle in 2021: A more upbeat outlook.
Testing’s role in delivery is also visible in delay statistics. GitLab’s 2019 survey of more than 4,000 developers, security professionals, and operations members found that 50% of each respondent group named software testing as the biggest reason development was delayed. In GitLab’s 2020 survey, testing was cited by 47% as the area most likely to cause delays, down from 49% the prior year. Planning was cited by 39% as a process area that slowed delivery, followed by code development at 30% and code review at 28%. These measurements come from different survey years and describe perceived delivery friction, not the time spent running unit-test suites. The 2019 finding is described in An inside look at software testing at GitLab.
Automation maturity and coverage
Broad test-automation maturity remains uneven. Only 12% of testers in GitLab’s 2020 survey said their organizations had full test automation. Nearly 35% said their organizations were more than halfway to full automation. About 25% said their organizations were about 25% automated, while about 12% said they were nearly fully automated. The rounded categories are accompanied by a more detailed response distribution in the same report:
| GitLab 2020 tester response | Share |
|---|---|
| No test automation | 7.52% |
| Just beginning to think about automation | 17.26% |
| More than halfway to full automation | 34.53% |
| About 25% automation | 25.81% |
| Finish line or nearly fully automated | 12.48% |
The detailed distribution is from Testers and DevSecOps. The report separates tester responses from the broader respondent pool, and the categories concern test automation generally. They should not be interpreted as unit-test coverage percentages.
GitLab’s 2021 survey summary reported that almost 25% of respondents had achieved full test automation, described as more than double the prior year’s reported share. The same summary found that 28% were at least halfway to full test automation, while 25% either had no test automation or were just starting to think about it. Because the 2021 figures come from an official survey summary page and the 2020 detailed distribution comes from a separate report presentation, the comparison is directional rather than a controlled longitudinal benchmark. It nevertheless indicates a larger reported role for automation alongside a substantial group still at an early stage.
Shift-left development and TDD
Shift-left testing moves quality work toward development rather than leaving it until a later testing phase. GitLab’s 2020 survey found that 74% of organizations had shifted testing left toward development. Within the same survey, about 31% said developers tested some of their code, about 25% said automated testing happened as code was being written, and about 17% said development and test worked together as close to real time as possible. Just about 14% said their organizations had not shifted testing very far left. These results describe workflow position and collaboration; they do not establish that every shifted-left organization used unit testing or TDD.
TDD was reported by about 9% of respondents in GitLab’s 2020 findings. That is a narrower practice than general developer testing: TDD places tests before or alongside implementation, whereas developer testing can occur after code is written. Keeping those categories separate matters when interpreting adoption. A 31% developer-testing result cannot be relabeled as 31% TDD adoption, and a 25% code-writing automation result cannot be treated as a direct measure of unit-test coverage.
The 2021 survey summary found that 9% of respondents said their teams had not shifted testing far enough left. It also reported that 25% either had no test automation or were just starting to think about it. This combination suggests that earlier testing and automation were related but distinct dimensions: a team may move testing earlier while still having limited automation, or may automate selected checks without adopting a fully shift-left workflow.
GitLab’s 2020 tester responses also describe changes in daily work under DevOps. A total of 25.79% said DevOps changed their daily responsibilities through more test automation. Another 15.29% said the repetitive nature of their job was much lower and they could do testing that mattered more. These are perceptions reported by testers, not measured productivity gains. The same response distribution included 2.04% selecting “other” when describing daily-responsibility changes.
Team structure and quality workflow
Where quality specialists sit in the organization affects how easily unit-test feedback can become part of development. In GitLab’s 2020 survey, 56% of responding companies had QA teams embedded with developers. By contrast, 22% of testers said QA was a separate organization, and 15% said QA was part of operations. The categories describe organizational structure, not the ownership of every test type.
Collaboration measures point in the same direction. Nearly 30% of GitLab’s 2020 testers said they were working more closely with developers because of DevOps. A separate response category showed 16.31% saying DevOps gave them a more visible seat at the table, while 10.70% said their daily responsibilities had not changed. The report also found that 33% of testers had closer collaboration with developers than before. In the same 2020 survey, 23% of testers said they were solely responsible for security in their organizations, illustrating why unit-test ownership and security-test ownership should not be assumed to be identical.
SmartBear’s Q4 2021 global online survey across 20 industries provides additional context about team size and review practice. It found that 37% of respondents worked on teams larger than 10 people, compared with 30% in 2020. The survey also found that 43% delivered software biweekly or more often. Among respondents satisfied or highly satisfied with code review, 55% said code review regularly pulled metrics reports. These measures come from 80% of Those Satisfied with Software Quality Participate in Tool-based Code Review Says Survey by SmartBear. They concern team and review practices broadly, rather than unit-test execution alone.
Testing delays and release decisions
Testing can support earlier defect detection while still creating a delivery bottleneck when feedback is slow, fragmented, or difficult to interpret. Tricentis’ 2021 survey of more than 500 managers and DevOps professionals found that 82% experienced either frequent or some slowdown when testing new software releases. The same percentage, 82%, said their organizations deferred releasing software until testing was done. The results are reported in Tricentis Report Finds Quality Trumps Speed When Releasing Software.
The Tricentis survey also measured perceived quality and architecture effects. A total of 58% agreed that DevOps testing reduces production issues. Meanwhile, 43% said dependencies between services made continuous testing challenging as each microservice was updated. In the opposite direction, 38% said microservices made testing easier because services were smaller and more discrete. These results do not isolate unit tests from integration, system, or other release testing. They do show why a fast unit-test suite may not remove every release constraint: service dependencies and the remaining test layers can still affect release timing.
GitLab’s 2020 delay figures provide a complementary view of process friction. Testing led the cited areas at 47%, followed by planning at 39%, code development at 30%, and code review at 28%. Taken together, these survey measures describe testing as both a quality safeguard and a common source of perceived delay. They do not prove that increasing unit-test volume alone would reduce the reported delays.
CI/CD, serverless projects, and execution patterns
Automation is increasingly connected with continuous integration and delivery, but the available data still shows gaps. GitLab’s 2021 survey reported that 41% of respondents had bots testing their code or an AI/ML tool in place for testing, compared with 16% in 2020. The 2021 figure combines two kinds of tooling. When separated, 25% said they used bots to test their code, and 16% said they used AI/ML to review code before a human saw it. These figures come from GitLab’s 2021 survey summary and are broader than unit-test automation.
GitLab’s 2020 tester response distribution included 2.39% selecting “other” for test-automation status. That category should remain separate from the named automation stages because the source does not define it as a maturity level. Similarly, the 25.79% reporting more test automation as a daily-responsibility change describes work impact, not a percentage of test cases automated.
Serverless projects show why project type and sample definition matter. In GitLab’s Lambda usage survey, approximately 20% of non-hobby projects had no testing at all. The statistic describes non-hobby projects in that survey’s sample, not all Lambda applications and not unit testing specifically. GitLab notes that the Lambda results came from a small, channel-biased sample and that some questions allowed multiple answers. The source is AWS Lambda usage survey results.
For software-testing teams, these figures support a measured interpretation of unit testing. Developer participation rose from 31% in GitLab’s 2020 survey to roughly 34% in its 2021 summary, while automated testing during code writing rose from 25% to 32%. Yet full automation remained a minority result in the detailed 2020 tester distribution, and release testing continued to slow delivery for many organizations in Tricentis’ 2021 survey. Unit tests are therefore best understood as one early feedback layer within a wider quality workflow whose maturity, ownership, architecture, and release context vary by organization.