Leading QA Shift Left Transformation
Part 1: From Quality Control to Quality Assurance
Of the many transformations I have been a part of as an engineering leader, changing the organization's testing mindset was always the most difficult yet the most effective for the company’s performance.
A QA Shift Left transformation is a multi-layered problem that touches upon:
The way software is designed—its architecture and structure,
The entire delivery process—from early specification to writing the code, testing, and deploying it,
The role of people in this process and how their jobs will be disrupted—engineers get more responsibilities, testers may become redundant in the organization,
Questioning our sense of security and beliefs about what it means for software to be well-tested, especially when thousands or millions of users use it.
In this series of posts, I will share my experiences navigating this lengthy process, facing people’s reluctance and fear, and overcoming my own doubts. In the end, I will share a concise framework for Practical QA Shift Left that will help you succeed in this transformation.
Let’s begin!
Why Should We Even Bother?
I led multiple teams through QA Shift Left transformations—frontend, mobile, backend—both as a leader and external consultant. For me, each story started very similarly:
On a strategic level, senior management communicated clearly that something must change in how the company manages its SDLC. “We must find a way to deliver 5x faster to keep up with our competitors.”
However, this message was perceived as nitpicking on the operational level (engineering teams or first-level management: engineering managers, team leaders). “C-level again wants to squeeze even more from already hard-working people.”
In the context of Quality Assurance, such misalignment usually comes from complacency. “A few years ago, our tech stack was totally out of control and failing all the time. Today, we have clear procedures. No change goes to production without permission from a QA tester; we have stable, multi-week release cycles and a battery of thousands of test scenarios.”
On paper, this process works well and is usually the result of months or years of hard work. Such a situation is challenging to argue against—especially if you know the entire “Shift-Left” process will disrupt it completely.
Before we start the transformation, let’s start with Why to ensure that we, as leaders, truly believe such a disruption is needed.
Quality Control Slows You Down
Most engineering leaders assume quality assurance is best tackled toward the end of the process—after the code is written, feature-complete, and ready to test. But here’s the big twist: that mindset often multiplies your defect costs and slows you down.
One study from Capers Jones’s Applied Software Measurement found that fixing a bug after release costs up to 200 times more than fixing it during development. Even in typical projects, an early-stage defect usually costs 10–100× more to repair when found downstream (e.g., in system testing or after release) compared to fixing it at creation.
Moreover, according to Capers’s research, around 50% of total project effort is often spent on finding and fixing issues. This makes defect rework the single most significant cost driver.
Hard to believe? If your company practices classic Quality Control, look at how long it took to release the first version of a big feature. Then, see how much extra effort it took to fix all the critical issues or how far the initial release day was pushed.
It doesn’t matter when your first release happens. What matters is when the feature starts bringing value to customers.
The rest of this post, where I provide use cases, empirical data, benchmarks for QA practices, and my thoughts on testing, is available for paying readers.