Shift Left Testing: What It Really Means in Practice | Amber Insights #007
Updated: Sep 8
By Amber Idumwonyi
"Shift left" has become one of the most frequently used phrases in modern software delivery.
The principle sounds straightforward:
Test earlier.
But after working across complex technology programmes and collaborating with multidisciplinary delivery teams, I believe that definition is incomplete.
Shift left is not simply about moving testing activities earlier on a project timeline.
It is certainly not about transferring the responsibility of Quality Engineers to Developers.
And it does not mean eliminating independent testing because Developers now write more automated tests.
Done properly, shift left represents something much more valuable:
Bringing quality thinking, testing considerations, risk identification, and feedback closer to the point where software decisions are made.
Understanding that distinction is important because organisations can claim to have implemented shift left while continuing to discover significant problems much later in delivery.
So what does shift left actually mean—and what does it look like when implemented effectively?
Why Do We Call It "Shift Left"?
Think about a traditional software development lifecycle represented from left to right.
Activities such as requirements and design appear towards the left.
Development follows.
Testing happens later.
Deployment and production appear towards the right.
In a traditional sequential model, significant testing activity may not begin until much of the software has already been developed.
That creates a problem.
If a tester discovers during system testing that an important requirement was misunderstood, the problem may no longer involve simply correcting a document.
Code has already been written.
Interfaces may have been developed.
Test cases may have been created.
Other functionality may depend on the implementation.
Correcting the original misunderstanding can therefore require considerable rework.
Shift left challenges this model by asking:
What quality activities could have happened earlier?
Perhaps the requirement could have been challenged.
Perhaps an acceptance criterion was ambiguous.
Perhaps an integration risk could have been identified during design.
Perhaps an automated check could have provided feedback immediately after a code change.
The objective is to identify problems closer to the point at which they are introduced.
Shift Left Is About Feedback
For me, one of the best ways to understand shift left is through feedback.
The longer a team waits for meaningful feedback about quality, the longer incorrect assumptions can survive.
Imagine a requirement states:
"Users should be able to update their personal details."
At first glance, that sounds reasonable.
But a Quality Engineer might immediately ask:
Which personal details?
Can every field be changed?
Are there fields users should not be permitted to modify?
What validation applies?
What happens when invalid information is entered?
Does changing certain information require additional verification?
What happens if the update fails?
Those questions are already testing the requirement, even though no software exists yet.
That is shift left in practice.
Testing begins with thinking, not execution.
Earlier Quality Conversations Can Prevent Defects
There is an important difference between detecting and preventing defects.
Suppose a Business Analyst, Developer and Quality Engineer review a requirement together and discover that two acceptance criteria contradict one another.
They clarify the expected behaviour before implementation begins.
No defect is raised.
No test fails.
No code needs to be corrected.
Yet Quality Engineering has delivered significant value.
The absence of a defect report does not mean testing did not happen.
It means the problem was prevented before it became a software defect.
This is one reason mature quality practices should not measure the contribution of testing solely by how many defects testers identify.
Sometimes the best defect is the one the team never has to create.
What Should Actually Move Left?
Shift left can happen across several areas of software delivery.
Requirements
Quality Engineers can review requirements and acceptance criteria before implementation.
The objective is not to rewrite the Business Analyst's work.
It is to examine requirements from a quality and testability perspective.
Are they clear?
Are they measurable?
Are important scenarios missing?
Are assumptions being made?
Can we determine objectively whether the requirement has been satisfied?
Design
Quality considerations can also influence technical design.
If a solution depends on several systems communicating correctly,
integration testing should not first be considered when those integrations are complete.
Teams can discuss dependencies, failure scenarios, test environments, data requirements, observability, and testability while the solution is being designed.
Development
Developers can receive faster feedback through practices such as unit testing, static analysis, component testing and automated checks.
Problems discovered seconds or minutes after a code change are generally easier to investigate than problems discovered weeks later during a large regression cycle.
Test Automation
Automation can also move closer to development.
Rather than waiting until an entire feature is complete before considering regression automation, teams can determine appropriate automated coverage while functionality is being developed.
But this brings us to an important misconception.
Shift Left Does Not Mean "Developers Are Now the Testers"
This is where I believe some implementations of shift left go wrong.
Quality is a shared responsibility.
But shared responsibility does not mean identical responsibility.
Developers have an important role in quality.
They can perform unit testing, review code, contribute automated checks, challenge requirements, and consider testability while developing solutions.
But increasing Developer involvement does not automatically remove the need for specialist Quality Engineering.
Developers and Quality Engineers approach software from different professional perspectives.
A Developer naturally has deep knowledge of how a solution was implemented.
A Quality Engineer deliberately investigates how that solution behaves across requirements, integrations, data combinations, unexpected conditions, business processes, accessibility needs, and user journeys.
Those perspectives complement each other.
Shift left should therefore strengthen collaboration between engineering disciplines, not collapse them into one role.
The Danger of "Shift Left in Theory"
I recently received an interesting response to an earlier Amber Insights article from an experienced Quality Automation Leader.
She made an important observation: organisations can talk extensively about shift left while struggling to implement it effectively in practice.
That distinction deserves attention.
A team might say:
"Our Developers now own more testing, so we've shifted left."
But ask a few deeper questions.
Are Quality Engineers involved when requirements are discussed?
Are acceptance criteria challenged before development?
Are significant quality risks identified early?
Is testability considered during technical design?
Do Developers and Quality Engineers collaborate on appropriate coverage?
Does the team receive useful feedback early enough to act on it?
Are later testing activities still providing an appropriate level of independent challenge?
If the answer to most of these questions is no, responsibility may have been redistributed, but quality has not necessarily shifted left.
Moving responsibility is not the same as moving quality thinking.
That distinction is critical.
Shift Left Should Not Create Blind Spots
There is another danger.
Earlier testing can become an excuse for reducing later testing indiscriminately.
"We tested it earlier."
But earlier testing and later testing answer different questions.
A component may work correctly in isolation and behave differently when integrated with several services.
A feature may satisfy its acceptance criteria and still create problems within an end-to-end user journey.
Automated checks may pass while an exploratory tester discovers unexpected behaviour.
A technically correct solution may still create accessibility or usability problems.
Shift left should therefore not mean:
Test early instead of testing later.
It should mean:
Build appropriate quality activities throughout delivery so that feedback happens at the most useful points.
Later in this series, when we explore Shift Right, we will examine the other side of this principle: what teams can learn from software after it reaches production.
The two approaches are complementary rather than competing philosophies.
A Practical Shift-Left Framework
So how can teams move beyond theory?
I use five questions to simplify the conversation.
1. What Can We Learn Before Development?
Review requirements, acceptance criteria, dependencies, business rules, assumptions, and significant quality concerns.
The objective is to identify uncertainty while changing direction is still relatively easy.
2. How Can We Make the Solution Testable?
Quality Engineers, Developers and technical specialists should consider how the solution will be validated.
Will appropriate environments exist?
Can dependencies be controlled?
Can useful test data be created?
Will logs or other diagnostic information be available?
Can important checks be automated at an appropriate layer?
Testability should be designed rather than discovered accidentally.
3. Where Can We Get Faster Feedback?
Not every check needs to wait for system testing.
Determine where unit, component, API, integration, static analysis, or automated regression checks can provide earlier information.
The goal is not automation for its own sake.
The goal is useful feedback at the earliest appropriate point.
4. What Still Requires Independent Investigation?
Some quality questions require human exploration, business understanding, end-to-end validation, accessibility assessment, or investigation across complex behaviours.
Do not remove valuable testing simply because earlier checks exist.
Ask what confidence each testing activity provides and what uncertainty remains.
5. What Are We Learning?
If defects continue escaping into later environments or production, investigate why.
Could the problem have been identified earlier?
Was an assumption missed?
Was coverage insufficient?
Was the requirement unclear?
Was the problem only observable after integration?
The purpose is not to force every defect further left.
It is to continuously improve where and how the team obtains quality feedback.
Where Does AI Fit?
Artificial Intelligence introduces another interesting dimension to shift-left practices.
AI can already assist teams with activities such as reviewing requirements, generating test ideas, identifying potential edge cases, supporting code analysis, creating test data, and accelerating automation development.
This creates opportunities to obtain quality feedback even faster.
But speed introduces an important challenge.
Faster feedback is only valuable when the feedback itself can be trusted.
AI-generated tests can be incomplete.
AI can misunderstand business context.
Generated scenarios can appear convincing while missing critical risks.
Automation generated quickly can create an illusion of coverage without meaningful assurance.
For that reason, I do not believe the objective should simply be:
"How can AI make testing faster?"
A better question is:
"How can we use AI to accelerate quality feedback while preserving appropriate human judgement and engineering assurance?"
That question deserves much deeper treatment, and I will return to it later in this series when we explore AI in Quality Engineering.
What Successful Shift Left Looks Like
You know shift left is becoming embedded when quality conversations begin to happen naturally.
Quality Engineers are invited into discussions before implementation.
Developers ask questions about testing and testability.
Requirements are challenged constructively.
Automation provides useful feedback during development.
Quality risks are visible.
Teams prevent some problems before they become defects.
And later testing becomes more focused because basic problems have already been identified earlier.
Most importantly, nobody says:
"That's QA's problem."
But equally, nobody says:
"We don't need Quality Engineers anymore because Developers test their own code."
Instead, the team understands that different disciplines contribute different expertise towards a shared quality objective.
That is the balance shift left should create.
Final Thoughts
Shift left is frequently described as testing earlier.
I believe it is more useful to think of it as learning earlier.
Learning whether requirements make sense.
Learning whether assumptions are correct.
Learning whether a design is testable.
Learning whether code behaves as expected.
Learning where risks are emerging.
And learning all of this early enough to do something useful about it.
Implemented badly, shift left can become little more than transferring testing responsibilities and reducing specialist testing.
Implemented well, it creates faster feedback, stronger collaboration, earlier risk identification, better testability, and greater confidence throughout delivery.
The goal is not to move the tester to the left of a diagram.
The goal is to move quality thinking closer to every decision that can affect the product.
That is what shift left should really mean.
About the Author
Amber Idumwonyi is a Senior Quality Engineering Leader with extensive experience delivering quality engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Read More:
Amber Insights | Issue 001 – Why Every Successful Software Project Starts with a Test Strategy
Amber Insights | Issue 002 – Testing Is Not a Phase; It Is a Mindset
Amber Insights | Issue 003 – Understanding Software Quality Beyond Finding Bugs
Amber Insights | Issue 004 – The Evolution from Quality Assurance to Quality Engineering
Amber Insights | Issue 005 – Risk-Based Testing: Focusing on What Matters Most
Amber Insights | Issue 006 – Building a Quality Culture Across Delivery Teams
Explore LEMP's Software Testing programme and learn how you can get started.
Comments