Shift left testing gets talked about a lot in the industry, but the theory is the easy part. Move testing earlier into the SDLC, catch defects before they reach production, reduce the cost of fixing- all straightforward on a slide.
The harder part is building the habits and processes that make it actually work across real projects, real deadlines, and real ambiguity.
At Gurzu, shift left isn’t a new initiative; it’s already embedded in how our teams operate. QA is involved from the requirement stage onward, working alongside developers rather than waiting for a build to test against.
This collaborative approach aligns with our philosophy of QA as a Service, where quality is embedded throughout the development lifecycle.
It also reflects our philosophy of owning quality from the beginning, where QA contributes to requirement discussions, identifies risks early, and helps shape a better product before development begins.
That said, shipping software this way still surfaces real challenges, and we want to share two scenarios from our own projects, along with the process changes we made as a result.
Why Shift Left, Technically Speaking?
Shifting left isn’t just “test earlier” in the abstract; in practice, it maps to concrete QA activities at each SDLC stage:
- Requirements stage: requirement walkthroughs, ambiguity reviews, defining acceptance criteria, and edge cases.
- Design stage: test case design against the proposed architecture, identifying integration points and data contracts that will need validation.
- Development stage: early involvement in unit test coverage, static analysis, and CI pipeline gates so that defects are caught at the commit level.
- Test stage: functional, API, and regression, non-functional testing layered on top of what’s already been validated upstream.
- Production stage: this is where shift left hands off to shift right, canary releases, feature flags, and production monitoring, which we cover further down.
The goal across all of these stages is the same: fewer escaped defects, faster delivery, and lower overall cost of quality, by fixing issues early in the software bug life cycle, rather than after deployment.
Scenario: Preventing Requirement Ambiguity Before Development Begins
Our team was already deep into a high-priority task when a client came to us with an extra request. They were planning a sales campaign, let’s just call it “PayPal Sales Day” for this story, and wanted to know if we could get a discount feature ready in time.
The system already had two discount types built in: one that applied to all payment methods, and one that applied only to PayPal. The client didn’t specify which one they meant. Since the campaign was literally named after PayPal, it felt like an obvious guess, so that’s the one we went with.
Of course, that was the buggy path. We spent real time digging into it, fixing calculation issues, testing edge cases, doing what felt like solid shift-left work, catching problems early.
Then, right before the start of the campaign, the client mentioned that they actually wanted the discount applied to all payment methods, which was, for the most part, already tested and verified.
However, we did not miss the notion of leaving behind faults and issues in the system because if they had used that payment method, which is PayPal only, it could have frustrated users due to incorrect calculation, a direct risk to transaction accuracy during a live promotional window.
Root cause
Looking back, the real mistake wasn’t technical at all, it was that we never asked. A simple question, “Which payment method are you planning to use for this?”, would have saved us hours of testing the wrong thing and let us stay focused on the higher-priority work we’d stepped away from.
Process change
Shift left testing, applied correctly, means requirement sign-off has to include disambiguation of any interpretation-dependent logic, payment methods, discount scopes, user segments, feature toggles, before test cases are written against them. We now require an explicit confirmation step on any requirement with more than one technically valid implementation path.
Outcome
This is a low-cost, high-leverage checkpoint. A single clarifying question at the requirement stage is orders of magnitude cheaper than the test and development effort spent validating the wrong implementation path.
Scenario: Extending QA Beyond Functional Validation
On a separate project - an AI-assisted product- our QA coverage was strong across the layers that typically get the most attention: Core functional flows, API contract validation, and data integrity checks. The application passed all functional acceptance criteria and was considered stable for release.
However, once the application was shared externally, a presentation-layer gap surfaced: the site’s favicon had never been updated from its default placeholder. It wasn’t a functional defect; nothing broke, no data was affected, but it was immediately visible to anyone viewing the site, and it signaled an incomplete product despite the underlying system being technically sound.
Root cause
Our acceptance criteria and test coverage were scoped around functional correctness, without an equivalent checklist for presentation-layer and branding elements, which don’t naturally surface through API or functional testing.
Process changes implemented
- Presentation checks added as a standing item in requirement documentation, not an optional nice-to-have.
- UI and branding consistency are incorporated directly into acceptance criteria as a part of Design QA, reviewed at the same gate as functional criteria. A final UI validation checklist is introduced as a release gate, run regardless of whether the underlying change was frontend, backend, or infrastructure.
Outcome
Technical stability and perceived product quality are not the same thing. A release can pass every functional gate and still be read as unfinished to the end user if presentation-layer validation isn’t a first-class part of the test plan.
Watch our Knowledge Ketchup session to see how Shift Left Testing plays out in practice.
Extending Left With Right: Production Validation Strategies
Shift left reduces risk before release, but some classes of behavior, real traffic patterns, real user segments, real load, can only be validated once software is live. That’s the role shift right testing plays in our overall strategy: not a replacement for shift left, but its production-side counterpart.
Some Shift-Right techniques we rely on:
- Canary releases: A new build or feature is rolled out to a small percentage of production traffic first. Error rates, latency, and business metrics are monitored against that subset before expanding to full rollout, limiting blast radius if an issue is present.
- Feature flag testing: Features are decoupled from deployment, allowing them to be toggled on or off in production without a redeploy. This supports controlled experimentation, gradual rollout, and immediate rollback if a flagged feature exhibits unexpected behavior, without the operational overhead of an emergency revert.
Together, shift left and shift right form a continuous validation loop across the full lifecycle: defects are caught as early as possible pre-release, and real-world behavior is continuously validated post-release.
Shift left testing, done well, isn’t a single practice; it’s a set of checkpoints distributed across the entire SDLC, each catching a different class of risk. Combined with shift right validation in production, it gives our team continuous visibility into quality from the first requirement conversation through to live traffic.
We’ll continue sharing lessons like these as we refine our process further. Whether it’s strengthening quality validation practices, improving release confidence, or embedding QA earlier in development, our goal remains the same: building better software from the very beginning.
