Sitemap

Shift Left Did Not Fix It

8 min readMay 4, 2026

--

TESTING’S COMFORTABLE LIES | PART 2

Press enter or click to view image in full size

After Part 1 of this series went out, a few people made a point worth addressing. The accountability conversation felt dated. “Quality is everyone’s responsibility” is a phrase from another era. The industry has moved on. Why are we still arguing about it?

It is a fair challenge, and I want to answer it directly before getting into the second lie, because the same challenge will come for this one, too.

Comfortable lies do not retire when they stop being true. They retire when they are no longer useful. “Quality is everyone’s responsibility” remains useful for organizations that want to reduce testing headcount without openly owning that decision. It still appears in transformation roadmaps. It still surfaces in all-hands meetings and agile coaching sessions. The phrase has not disappeared. It has just been repeated often enough to stop feeling like a choice and start feeling like a fact.

Shift left is in a similar position. Some readers will say they do not even use that term anymore. And that might be true in their organization, in their particular language. But look at what replaced it. “Continuous testing.” “Quality built in from the start.” “BDD from day one.” “Test early and often.” Different words, same idea, same unresolved problem underneath.

“The comfortable lie does not always keep its original name. It keeps its shape.”

This series is not about the vocabulary. It is about the thinking underneath the vocabulary. About the ideas that became convenient enough to stop being questioned. That is what we are here for.

Where shift left came from and why it made sense

The argument for shift left was not wrong. That is worth saying clearly.

Testing at the end of the delivery process was genuinely problematic. Defects found in UAT are expensive to fix. Defects found in production are more expensive still, and the costs go beyond the code. Late discovery means late decisions, delayed releases, unhappy customers, and the kind of blame conversations that nobody enjoys. If you could find problems earlier, closer to the point where they were created, the logic was sound: fix them while the context is fresh, before they compound, before they become someone else’s problem downstream.

The movement that grew around this idea made sense as a correction. Get testers involved in requirements conversations. Review acceptance criteria before development starts. Identify ambiguity, risk, and missing assumptions early rather than discovering them through a failing test case three sprints later. The principle was good. The execution is where things went quietly wrong.

What shift left became in practice

Shift left became a structural instruction rather than a thinking instruction. Organizations read “test earlier” and translated it into “move the tester earlier.” Testers were repositioned upstream. They were assigned to squads. They attended refinement meetings, story reviews, and sprint planning sessions. In the process diagram, testing now appears at the beginning rather than at the end. Leadership was satisfied. The transformation slide looked clean.

What nobody clearly defined was what testers were actually supposed to do in those earlier conversations. In many organizations, the answer turned out to be: attend them. Review things. Be present. Stay agile. The mandate did not move with the people. The authority did not follow the process change. The expectation of challenge, the protected time for genuine risk thinking, the permission to slow something down when assumptions were unclear: none of that came along for the ride.

In a significant number of cases, shift left quietly became: write automation earlier, review stories occasionally, stop calling yourself a tester, and trust that your proximity to earlier conversations will somehow produce better quality outcomes. The fog that Part 1 described, the accountability fog that lives inside the phrase “everyone owns quality,” did not lift when teams adopted shift left. It moved upstream with the testers and settled there just as comfortably as it had before.

The bank that shifted left without moving the risk

A large financial services organization I worked with was dealing with a problem that will sound familiar. Releases were delayed. UAT was painful. Production incidents were increasing. Testing was blamed for being a bottleneck. Leadership decided the answer was shift left.

The logic on paper looked sensible. Testers would be involved earlier in the process. Developers would write more automated tests. Acceptance criteria would be reviewed before development started. The transformation slides were well-designed, which is usually the first warning sign.

The organization renamed its testing approach from late-cycle testing to shift left quality engineering. Testers were assigned to squads from the start of each sprint. User stories now required a Definition of Ready and a Definition of Done. Automation targets appeared on team dashboards. Testers were told to focus on exploratory testing, risk analysis, and coaching their squad colleagues.

Six months later, the language had changed completely. The problems had not.

Defects found late were no longer called defects found late. They became escaped story gaps. Requirement ambiguity was no longer called poor analysis. It became backlog refinement debt. UAT failures were no longer called testing delays. They became business validation feedback. Production incidents were no longer called release quality issues. They became operational learning opportunities. Testing bottlenecks were no longer called testing bottlenecks. They became flow constraints.

“The organization had shifted the vocabulary left. The thinking stayed exactly where it was.”

The root problem was not hard to identify once you were inside it. Testers were invited earlier but were not given decision-making influence. When testers questioned assumptions, product owners treated it as overthinking. When testers asked for clearer acceptance criteria, the response was that the team had to stay agile. When testers raised integration risks, architects said those would be handled in a later sprint. When testers challenged release confidence, leadership asked whether the test execution dashboard was green.

The testing activity moved earlier. The risk conversation did not.

Automation became part of the theatre as well. Teams proudly reported higher automation coverage figures, but much of that coverage checked happy paths, mocked away important dependencies, or validated what developers already knew worked. The most dangerous risks lived between services, across data states, in migration scripts, in third party system behaviour, and in operational conditions that staging environments never accurately represented. Those risks did not care that unit test coverage had improved.

The organization eventually arrived at an uncomfortable realization. The problem was not timing. It was authority. Moving testing activities earlier in the lifecycle was not the same thing as moving quality-related decisions earlier in the lifecycle. Only when the organization changed the questions did anything actually change. Not because shift left was adopted more thoroughly, but because the team stopped treating testing as an earlier activity and started treating it as an earlier thinking discipline.

Moving the location without moving the thinking

The shift left failure pattern is consistent enough across organizations to be worth naming clearly. A team is struggling with late defect discovery. Someone proposes shift left as the solution. Testing activities are repositioned upstream. The process diagram changes. The metrics change. The reporting language changes. Leadership is confident the problem has been addressed. Six months later, escaped defects are still arriving, but they now have different names and the post-incident reviews have better vocabulary.

What did not change is the relationship between testing and decision making. Testers moved left on the diagram while the real decisions stayed locked in rooms where testing had no voice and no authority.

“A tester who attends a refinement meeting but cannot block a story for unclear acceptance criteria has not shifted left. They have shifted their schedule.”

A team that writes automated checks earlier but never asks whether those checks are testing the right things has not shifted left. It has shifted its pipeline. The phrase implied that timing was the barrier. It was not. The barriers were authority, incentives, and the willingness of organizations to let quality-related thinking influence decisions with commercial and political weight attached.

The same fog, repositioned

Looking at the first two lies together, a pattern becomes visible.

Lie 1 said quality belongs to everyone. The result was that accountability disappeared into a collective sentiment that nobody could enforce or examine. The fog was everywhere, which meant it was nowhere.

Lie 2 said move testing earlier. The result was that testers moved upstream while the accountability problem remained exactly where it was. The fog relocated. It looked like progress from the outside because the process diagram changed. The incidents kept arriving because the thinking did not.

Both lies had the same shape. Both offered a structural or rhetorical solution to what was fundamentally a thinking problem. Both made it possible for organizations to announce that they had addressed quality without actually designing a system that produced it. Both generated enough visible activity, enough terminology change, enough dashboard improvement, to sustain the belief that something meaningful had changed.

A better framing

Shift left is not a bad idea. It is an incomplete one, and the incompleteness is what causes the damage.

Moving testing earlier in the delivery process only produces better outcomes when you also move the mandate, the authority, the expectation of challenge, and the protected time for genuine thinking. Without those, you have moved your testers without moving your relationship with risk. The process diagram changes. The accountability does not.

The questions that actually matter are not about timing. They are about whether testing has the authority to influence decisions, not just attend the meetings where decisions have already been made. Whether testers are expected to challenge, not just review. Whether the organization treats a tester blocking a story for insufficient clarity as a quality signal worth examining, or as a process obstacle to work around.

Shift left asked when testing happens. The question that needed asking was what testing is allowed to change. Those are not the same question. The first is easy to answer with a process diagram and a metric. The second is uncomfortable, political, and necessary.

The comfortable lie is that the first question, once answered, takes care of the second. It does not. It never did.

What comes next

The industry did not stop at shift left. It kept looking for a solution to the accountability problem that Lie 1 created and Lie 2 failed to fix. Then AI arrived. Not as a novelty, but as an answer. AI generates tests now. It writes scripts, produces coverage reports, flags anomalies, and summarises results faster than any testing team has ever operated.

Organizations look at this activity and conclude that testing is happening. The dashboard has never looked greener. The confidence has never been less earned.

The third comfortable lie is already running in production: AI is doing the testing now. The reason it is the most dangerous lie in this series is the assumption buried inside it: that because AI generates a test, it has understood the risk the test was meant to address. It has not. AI predicts. There is an enormous difference between a system that generates the statistically likely next output and a discipline that asks whether confidence in delivery is actually earned.

The first lie scattered accountability across a team. The second lie moved it upstream without fixing it. The third lie is about to hand it to a machine.

“The fog is not lifting. It is learning to generate its own reports.”

--

--

Brijesh Deb
Brijesh Deb

Written by Brijesh Deb

In God we trust, everything else I Test! Views expressed here are personal.