I have never met a single person in software who disagrees with shift-left testing in theory. Earlier testing catches cheaper bugs. The data is clear. The logic is obvious.
And yet.
Try walking into a design review as a QA engineer. Try asking a product manager if you can sit in on sprint planning. Try suggesting that testing should start before a single line of code exists.
You will get polite resistance. You will get scheduling conflicts that are not really conflicts. You will get "we'll loop you in later" emails that never arrive.
I have been running QA teams for years, and the hardest part of shift-left has never been the testing. It has been the politics.
The math that everyone already knows
IBM published the numbers decades ago, and they have been validated repeatedly since. A bug found during requirements costs roughly $100 to fix. The same bug found in production costs $10,000 or more. That is a 100x multiplier.
The Systems Sciences Institute at IBM put specific ranges on this:
- Requirements phase: $100 per defect
- Design phase: $300-600 per defect
- Implementation: $1,000-2,000 per defect
- System testing: $3,000-5,000 per defect
- Production: $10,000+ per defect
NIST backed this up with their own study estimating that software bugs cost the US economy $59.5 billion annually, with more than half of that cost attributable to bugs that could have been caught earlier.
These are not controversial numbers. Every engineering leader has seen some version of this chart. It shows up in conference talks, blog posts, and onboarding decks at half the tech companies on the planet.
So why does testing still start late?
The resistance nobody talks about
Here is what actually happens when you try to shift left.
Developers feel watched. When a tester shows up to a design meeting, some developers interpret it as distrust. "Why do we need QA here? We haven't even written anything yet." The subtext is: you are here to find problems with my thinking, and I did not sign up for that.
Product managers feel slowed down. Sprint planning already takes too long. Adding QA concerns means discussing edge cases, error states, and unhappy paths before anyone has committed to a direction. PMs want to move fast and refine later. QA wants to think through failure modes before the work begins. Those two instincts collide.
Testers feel unwelcome. After a few rounds of being the person who raises problems in meetings full of people who want solutions, many QA engineers stop pushing. They wait for the handoff. They test what they are given. The shift-left conversation dies quietly.
I have watched this pattern play out at dozens of organizations. The people are not wrong for feeling what they feel. The resistance is human, and pretending it does not exist is why most shift-left initiatives fail.
Two clients, two outcomes
I want to share two real situations because the contrast is stark.
Client A brought us in during the requirements phase. We sat in on product discussions. We reviewed wireframes and user stories before development started. We wrote test scenarios alongside acceptance criteria.
The result: their production bug rate dropped by roughly 50% within three months. Not because we were catching more bugs in testing, but because our questions during requirements eliminated entire categories of bugs before they were ever coded. Things like "what happens if the user has two active sessions?" or "does this flow work for users who skipped onboarding?" would surface in design, and the team would address them in the spec.
Client B brought us in at staging. We got builds after development was done, filed bugs, and watched them get fixed in the next sprint. Classic.
Their bug count in production stayed roughly flat quarter over quarter. They kept shipping the same types of bugs: missing validation on edge cases, broken flows for uncommon user paths, accessibility gaps nobody thought about. The bugs were not hard to find. They were predictable. They were the kind of bugs that disappear when someone asks the right questions during design.
Same QA team. Same processes. Same tools. The only difference was when we entered the picture.
What shift-left actually looks like in practice
Shift-left is not about running unit tests earlier, though that helps. It is about involving testing thinking earlier. There is a difference.
Here is what works:
Test case design during requirements. Before a story moves to development, write the test scenarios. Not automated scripts. Just plain-language descriptions of what you are going to verify. This forces everyone to agree on expected behavior before anyone starts building.
QA review of acceptance criteria. Testers are better at finding ambiguity in specs than developers are, because testers think about what could go wrong. A developer reads "user can update their profile" and thinks about the happy path. A tester reads the same story and asks: what fields are required? What happens with special characters? Can they update while another session is active? Is there a character limit?
Bug categorization and traceability. Track where bugs originate. If 60% of your production bugs trace back to unclear requirements, that is your argument for QA in the requirements phase. Hard numbers beat theoretical frameworks every time.
Pair sessions between QA and dev. Not formal meetings. Just a developer and a tester spending 20 minutes talking through a feature before implementation. These conversations catch misunderstandings that would otherwise become bugs.
Getting past the resistance
Here is the honest advice, based on what I have seen work.
Start small. Do not try to get QA invited to every meeting. Pick one feature or one team. Demonstrate value with a contained experiment. When the team sees fewer bugs coming back from that feature, they will ask for more QA involvement on their own.
Lead with questions, not criticism. The fastest way to get uninvited from design meetings is to be the person who says "that won't work." Instead, ask questions. "How should this behave when the API is slow?" is more welcome than "you haven't considered the timeout case." Same concern, different framing.
Show the cost data for your own project. The IBM numbers are nice but generic. What actually moves people is your project's own data. Pull the bug reports from the last quarter. Categorize them by root cause. Calculate the time spent fixing production bugs versus the time it would have taken to catch them in requirements. That is a number your PM will care about.
Accept that shift-left is a spectrum. You do not need QA at every design meeting to get value. Even moving from "QA starts at staging" to "QA reviews stories before sprint commitment" is a significant shift. Take the win.
Where automation fits
Test-driven development, automated regression suites, CI/CD pipelines with quality gates: all of these are shift-left tools. They move verification earlier by making it cheaper to run tests frequently.
But automation is the easy part. You can set up a CI pipeline in an afternoon. Getting a product manager to add 15 minutes of QA review to their sprint planning ceremony takes months of relationship building.
The teams that get the most out of shift-left are the ones that combine both: automated checks that run early and often, plus human testers who participate in the thinking that happens before code exists.
The uncomfortable truth
Shift-left testing works. The data is overwhelming. The case studies are consistent. Organizations that test earlier ship better software with fewer production incidents.
But it requires something that no framework or tool can provide: it requires developers and product managers to voluntarily share their planning process with people whose job is to find problems. That is an act of trust, and trust takes time.
If you are a QA leader trying to push shift-left, be patient. Build relationships before building processes. Demonstrate value in small doses. And accept that the human side of this change is harder than the technical side.
The bugs do not care about your feelings. They will be cheaper to fix early whether your team is ready to hear that or not. Your job is to make them ready.
We write about testing practices, QA strategy, and the realities of running independent QA teams at betterqa.co/blog.
Top comments (0)