Explore the Impact of Shift-Left Testing
Strongly Agree: 9%
(n=620)
Disagree: 22%
Agree: 35%
Strongly Disagree: 12%
Undecided: 22%
Undecided: 15%
Strongly Agree: 16%
(n=121)
Disagree: 18%
If you rely on developers to test new features immediately after coding, and it takes at least 8 hours per week
to test new features, do you agree this is impacting those developers’ productivity?
Agree: 36%
Strongly Disagree: 15%
█ 5-8: 27%
(n=273)
For organizations with 500-plus employees releasing features multiple times per month, how many hours per week
does your team spend testing immediately after coding?
█ < 2: 6%
█ > 8+: 44%
█ 2-5: 23%
(n=946)
█ Yes: 86%
For organizations releasing multiple times per month, does your organization test features immediately
as they are being developed?
█ No: 14%
█. 5-8: 27%
█. < 2: 6%
█. 2-5: 23%
█ > 8+: 44%
57%
How shift-left is impacting teams
While shift-left improves quality, it can have a significant impact on developers and QA teams,
who now have to test more often. Our survey found that nearly half of large organizations
releasing frequently now spend at least a full workday on testing new features every single
week.
40%
20%
Save the costs of later-stage bug fixes
Developer buy-in
50%
45%
Shift-Left Has Already Happened
Reduce the need for hot-fixes
0%
Reduce the amount of bugs released to end users
10%
© 2021 Applause App Quality, Inc.
(n=317)
Shift-left is already happening
Shifting testing to the left is well-established at this point. Our data found that 86% of
organizations that release frequently are already testing immediately after the code is
complete.
Slow test results
18%
31%
60%
In April 2021, Applause surveyed more than 1,800 QA, product, engineering and DevOps
professionals across the globe on the state of shift-left testing. We found that many
organizations are already testing features immediately after coding – but it’s taking
development and QA teams at fast-moving organizations away from their day jobs. Here’s what we
learned.
How It’s Impacting Your Teams
How shift-left is helping
Large companies shifting left report multiple benefits in their SDLC. The top three benefits,
according to our survey, were reducing the number of bugs released to end users, saving costs on
late-stage bug fixes and reducing the amount of hot-fixes.
–––
For large companies releasing frequently who have shifted left, how has shifting left helped
your dev/QA/product efforts?
(n=389)
Developers are too busy with coding
48%
Learn more at: applause.com/in-sprint-testing
37%
Shift left without burdening your teams
Developers and internal QA teams aren’t your only options for testing new features. Applause’s
In-Sprint Testing brings a repeatable process to shifting left that augments your internal teams
and ensures you receive test results on new features immediately after coding, without diverting
your internal teams from other priorities.
Shift-left can impact new code development
Developers in particular want to build new code, and this is why organizations value them so
highly. But forcing them to test new features takes them away from code-building. Over 52% of
teams that rely on devs for testing and spend 8+ hours a week on testing agree that testing new
features is impacting their developers’ productivity.
30%
39%
Context switching causes delays
Because developers are so busy, it can be difficult for them to re-acclimate themselves to
feature requirements and code they (or someone else) wrote days or weeks earlier – with 44%
admitting context switching is an issue.
Coding vs. testing
In fact, we can see that among organizations who are not shifting left, the No. 1 barrier is
that developers are too busy with coding.
–––
What are the biggest barriers within your organization to shifting left?
(Companies who have not yet shifted left)
Development and QA efforts are too siloed
Shift-left can impact new code development
Developers in particular want to build new code, and this is why organizations value them so
highly. But forcing them to test new features takes them away from code-building. Over 52% of
teams that rely on devs for testing and spend 8+ hours a week on testing agree that testing new
features is impacting their developers’ productivity.
How shift-left is helping
Large companies shifting left report multiple benefits in their SDLC. The top three benefits,
according to our survey, were reducing the number of bugs released to end users, saving costs on
late-stage bug fixes and reducing the amount of hot-fixes. –––
For large companies releasing frequently who have shifted left, how has shifting
left helped your dev/QA/product efforts?
Context switching causes delays
Because developers are so busy, it can be difficult for them to re-acclimate themselves to
feature requirements and code they (or someone else) wrote days or weeks earlier – with 44%
admitting context switching is an issue.
Coding vs. testing
In fact, we can see that among organizations who are not shifting left, the No. 1 barrier is
that developers are too busy with coding.
–––
What are the biggest barriers within your organization to shifting left?
(Companies who have not yet shifted left)
How shift-left is impacting teams
While shift-left improves quality, it can have a significant impact on developers and QA teams,
who now have to test more often. Our survey found that nearly half of large organizations
releasing frequently now spend at least a full workday on testing new features every single
week.
Shift-left is already happening
Shifting testing to the left is well-established at this point. Our data found that 86% of
organizations that release frequently are already testing immediately after the code is
complete.
Shift-left is already happening
Shifting testing to the left is well-established at this point. Our data found that 86% of
organizations that release frequently are already testing immediately after the code is
complete.
Strongly Agree: 16%
█ Agree: 36%
█ Undecided: 15%
█ Disagree: 18%
█ Strongly Disagree: 15%
Shift-left can impact new code development
Developers in particular want to build new code, and this is why organizations value them so
highly. But forcing them to test new features takes them away from code-building. Over 52% of
teams that rely on devs for testing and spend 8+ hours a week on testing agree that testing new
features is impacting their developers’ productivity.
If you rely on developers to test new features immediately after coding, and it takes at least 8
hours per week to test new features, do you agree this is impacting those developers’
productivity?
Shift left without burdening your teams
Developers and internal QA teams aren’t your only options for testing new features. Applause’s
In-Sprint Testing brings a repeatable process to shifting left that augments your internal teams
and ensures you receive test results on new features immediately after coding, without diverting
your internal teams from other priorities.
Context switching causes delays
Because developers are so busy, it can be difficult for them to re-acclimate themselves to
feature requirements and code they (or someone else) wrote days or weeks earlier – with 44%
admitting context switching is an issue.
It is cumbersome to reacclimate myself to code from days or weeks earlier.
Learn more about In-Sprint Testing
How It’s Impacting
Your Teams
Coding vs. testing
In fact, we can see that among organizations who are not shifting left, the No. 1 barrier is
that developers are too busy with coding.
What are the biggest barriers within your organization to shifting left? (Companies who have not
yet shifted left)
How shift-left is helping
Large companies shifting left report multiple benefits in their SDLC. The top three benefits,
according to our survey, were reducing the number of bugs released to end users, saving costs on
late-stage bug fixes and reducing the amount of hot-fixes.
For large companies releasing frequently who have shifted left, how has shifting left helped
your dev/QA/product efforts?
How shift-left is impacting teams
While shift-left improves quality, it can have a significant impact on developers and QA teams,
who now have to test more often. Our survey found that nearly half of large organizations
releasing frequently now spend at least a full workday on testing new features every single
week.
For organizations with 500-plus employees releasing features multiple times per month, how many
hours per week does your team spend testing immediately after coding?