How to Shift Testing Left, Practically
Part 2 of Leading QA Shift Left Transformation
In the previous article, we looked at why late-stage Quality Control holds your engineering team back, bloating defect costs and slowing release cadence. We also discussed how high-performing organizations integrate testing earlier (and everywhere) in development to accelerate delivery, reduce defects, and keep developers happy.
But how exactly do you introduce these Shift-Left practices in real life? This article shares a practical framework for engineering leaders – to start and successfully lead through this transformation. Let’s get into the nuts and bolts of “shifting left” in QA.
Start With a Strategy
QA Shift Left is not a one-time action. It's a lengthy process that, in some organizations, never ends. For many, “Shift Left” says nothing. Many others will be skeptical, and it's not enough to say, “Google works this way.” “We are not Google,” you will hear back.
Before you jump into action and either start discussing the bright future of Continuous Delivery or go directly into fixing broken Unit Tests, it’s worth doing a strategy exercise first. It will help you understand clearly why you need such disruption and whether it’s really worth it.
Start by formulating a clear “strategy kernel” for this transformation, following Richard Rumelt’s principles I described in Engineering Strategy Framework. Identify the core problems in your current SDLC and QA processes (e.g., high production defect rates, slow feedback loops, long time-to-market, long recovery time) – this is your diagnosis.
Then craft a guiding policy: for example, “Quality is everyone’s responsibility at each stage of development.” Or "Become Elite in all of the core DORA metrics."
Finally, outline coherent actions to execute this policy with a set of coherent actions. This might include adopting test-driven development, integrating “quality gates,” and automating tests in the CI pipeline that, once red, cannot push code to production.
Ensuring the transformation plan has this strategic “kernel” (problem, policy, actions) will keep efforts focused – not on the idea of shift-left transformation but on the expected outcomes you will deliver.
I honestly recommend spending a few days with Engineering Strategy Framework, filling in this framework with data, and keeping it close so you can jump in whenever you need to rethink the entire plan again.
1. Quality Begins with Requirements
Shift-left intuitively is about reducing the complexity of tests and shifting them to the places (in the testing pyramid) where it’s easier to maintain them and quicker to execute. But what everyone misses is that the shift-left journey starts before a single line of code is written.
Low coverage and engineers’ reluctance to write tests often come from the fact that they don’t know exactly what should be tested. Empty tickets and tasks like “do this” with a single screenshot. Or a task with literally tens of requirements but no clear user story. No surprise, devs default to “let’s build it, and we’ll see.” This also leads to late-stage testing and low-quality architecture.
INVEST Criteria: Ensuring Clarity
In a Shift-Left culture, the Product Owner, QA, and Developers collaboratively define acceptance criteria—often using Behavior-Driven Development (BDD) or “specification by example.”
One quick rule of thumb is the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable). When your user story meets these criteria, it’s ready for development and test:
Independent: The story can be built and tested without dependencies.
Negotiable: The story should be used to start a discussion within the team instead of defining a fixed workflow. Focus on what and why, not how.
Valuable: Each story needs to define the value brought to the user.
Estimable: The team should be able to determine how much time is needed to develop the story.
Small: The story should be small enough to be finished quickly (fits in a single sprint).
Testable: Acceptance criteria describe precisely how you’ll validate the story.
Bonus point: Once the story is done, it should go live straight to production. See Continuous Deployment in Practice.
This isn’t just a formality. Many late-stage bugs can be traced back to ambiguous or incomplete requirements.
For instance, consider a simple checkout flow: “Users can apply a discount code.” A robust acceptance criterion might say:
“Given a standard user with items in their cart totaling $100,
when they apply discount code SAVE10,
then the final total is $90,
and the user sees a ‘Discount applied successfully’ message.”
In plain language, you’re already describing test conditions before coding. Clarifying edge cases at the requirement stage (e.g., what if the discount code is expired?) prevents entire categories of downstream surprises.
That’s shift-left in action.