Quality is a team sport. Not a gate.
It is Monday afternoon. You just returned from holiday, open Jira, and see a Ready for Test lane that has grown to twelve or more tickets while you were away.
Suddenly, people start talking about QA being a bottleneck.
But the bottleneck is rarely one person. It is usually the way the work flows through the team.
For years, many companies followed a model that felt logical:
- Developers build.
- QA tests.
- QA gives the final approval before release.
This approach can work well, especially in certain environments. The difficulty appears when companies grow. When the number of developers increases faster than the QA team, quality does not automatically scale with it.
Instead, a queue starts forming.
Context gets lost. Tickets move back and forward. Problems are discovered weeks after decisions were made.
Usually, nobody intended for this to happen. People are simply working within the process they have.
In this post, I want to share my view on what Shift Left means, what role QA should play and why quality works better when the whole team contributes.
What Shift Left actually means to me
"Shift Left" is a term that gets used a lot, and that sometimes creates confusion.
There is no single way to implement it. Every company, team and product has different challenges.
For me, Shift Left is mainly about preventing problems from being created in the first place.
It means asking better questions earlier, challenging assumptions and involving the right people before decisions are already locked in.
A question during refinement might take fifteen minutes. The same question after development is finished, after context has been lost, or after something reaches production can cost days.
It means:
- Making sure we understand the problem before building a solution.
- Identifying risks before they become defects.
- Involving the right people at the right moment.
- Creating shared ownership instead of pushing quality towards one final step.
Shift Left is not about moving QA activities earlier in the timeline. It is about making quality part of the decisions that happen throughout the development process.
QA is not the same thing as testing
When people hear QA, they often think about testing.
Testing is a major part of QA, but the role is broader than executing test cases.
A developer is not only someone who writes code. A product manager is not only someone who writes requirements. In the same way, QA is not only someone who verifies whether something works.
QA is about increasing confidence in what we build.
That means understanding risks, questioning assumptions, helping teams define what "ready" and "done" actually mean, improving collaboration and learning from problems instead of only fixing individual bugs.
Testing sits within all of that.
This is also where I think there can sometimes be confusion around certifications like ISTQB, which are still common on QA CVs.
There are many excellent QA engineers with ISTQB certifications, and the certification teaches useful concepts around testing techniques, coverage, test levels and foundations.
The issue appears when certification knowledge becomes the complete definition of QA.
A lot of traditional testing knowledge naturally fits into a verification model:
- One team builds.
- Another team checks.
- QA provides confidence before release.
That model is not wrong. It solves a real problem.
However, as teams and products grow, it can become harder to scale when quality decisions are concentrated around one stage of the process.
A QA engineer working in a Shift Left environment still tests, thinks about coverage and creates automation.
The difference is that they also help teams think about risk, impact and confidence earlier.
Questions they might ask include:
- Are we solving the right problem for the user?
- What assumptions are we making?
- What could go wrong?
- How will we know this works?
- Who else needs to be involved?
- What impact could this have on future changes?
These conversations are often where QA can have the biggest influence.
Everyone contributes to quality
Shift Left is sometimes misunderstood as reducing QA involvement or making developers responsible for everything.
That is not how I see it.
Developers testing their own work is part of good engineering. QA engineers still test and build automation. The difference is where each person focuses their attention.
- A small UI change and a change to authentication do not carry the same level of risk.
- A copy update does not require the same validation approach as a payment flow.
This is where a risk-based approach helps.
The team should understand the impact of a change and decide together what level of confidence is needed.
The conversation should not be:
"QA does not need to look at this."
It should be:
"Given the risk and impact, what is the best way to validate this?"
Finding a problem while working on a feature is usually much easier than discovering it weeks later.
The context is still fresh. The decisions are still understood. The people involved can solve it together.
That creates faster feedback loops for everyone.
Same goal, different approaches
Most people working in IT want the same thing.
They want to build reliable products, avoid unnecessary incidents and create a good experience for users.
The discussion is usually about how quality is achieved.
The traditional approach creates confidence through a final verification step.
The Shift Left approach creates confidence throughout the process by involving people earlier, discussing risks and making better decisions before problems appear.
Both approaches can work.
The important part is understanding what fits the environment.
A final validation step can make sense in some situations. The difficulty is relying on that step as the main place where quality is created.
When teams grow, that responsibility becomes harder to scale.
Moving towards Shift Left requires changes in habits.
People need to understand why the change is happening, what is expected from them and how it helps them work better.
The best improvements usually happen when teams understand the reason behind the change, not when a new process is simply introduced.
What this looks like in practice
Over the years, I have worked on this with different teams and companies. The focus was different depending on where the team was at the time.
Examples include:
- Explaining what Shift Left means and why it can help.
- Changing expectations around the QA role.
- Helping teams understand ownership of quality.
- Creating small experiments to compare different approaches.
- Using data and examples to understand where the process creates problems.
- Helping developers become more comfortable with testing.
- Answering questions and discussing concerns openly.
- Introducing improvements step by step with the team.
The important part is making sure the change solves an actual problem.
Shift Left should not happen because it is popular or because another company does it.
The better question is:
"We have this problem. How can we improve the way we work?"
Metrics, examples and feedback help make those conversations more practical.
Final thoughts
I still enjoy the technical side of QA: building frameworks, improving tooling, automating where it adds value and solving problems with code.
But after working with different teams, I have realised that the biggest impact of QA often comes from improving how teams think about quality.
Sometimes the biggest improvement is a team asking better questions earlier, understanding risks before they become problems and working together more effectively.
Those changes are less visible than creating a new framework or finding a large number of bugs, but over time they can have a much bigger impact.
Quality is not something a team checks at the end.
It is something a team creates throughout the process.
Quality is a team sport. Not a gate.
Alex Hovenkamp