How a dedicated QA team can actually lower quality
In the 1970s, economist Sam Peltzman observed an interesting phenomenon: when safety measures are introduced, people tend to compensate by taking more risks. This became known as the Peltzman Effect, where perceived safety leads to behavioral changes that can offset the intended benefits. Just like people driving 4x4’s in the snow, believing that you’re safer can lead to greater danger through riskier behavior.
The same effect is alive and well in software development, particularly in how teams handle testing.
🧱The "Throw it Over the Wall" Mindset
In many organizations, testing is treated as a safety net, but one that is external to the development process. Developers write their code, do some cursory checks, and then throw it over the wall to QA or an external testing team. The reasoning? “They’ll catch anything we missed.”
On the surface, this setup seems safe. Dedicated testing teams should, in theory, improve quality by providing an independent check before release. But in practice, this structure often incentivizes developers to take more risks, cut corners, and rely on testers to clean up the mess.
The Peltzman Effect in action. ➡️
How "Over the Wall" Testing Increases Risk
1️⃣Reduced Ownership of Quality
When developers know a separate testing team will validate their work, they are less inclined to test rigorously themselves. Why bother thoroughly unit testing when “QA will catch it”? This mindset leads to more defects, longer feedback loops, and lower-quality code.
2️⃣Delayed Discovery of Issues
Throwing testing over the wall creates a batch-and-queue system. Developers finish a feature, move on to the next, and days (or weeks) later, QA reports an issue. By that time, the original developer is mentally out of context, increasing debugging time and rework.
3️⃣False Sense of Security
Teams assume that because they have a QA function, the product must be high quality. But if defects keep slipping through, the actual problem is in the development process—not the testing phase. Relying on an external safety net prevents teams from improving their upstream quality practices.
4️⃣Us vs. Them Mentality
The more testing is seen as an external function, the more friction arises between developers and testers. QA becomes the “gatekeeper,” leading to adversarial relationships instead of a shared responsibility for quality. Developers get frustrated by “picky” testers, and testers get frustrated by sloppy code. Collaboration suffers.
The Alternative: Shift Left and Own Quality
To break the Peltzman Effect, developers need to own quality from the start. That means:
⭕ Shifting Testing Left: Catch issues earlier by integrating unit tests, automated tests, and continuous integration.
⭕ Pairing and Code Reviews: Developers reviewing each other’s code improves quality at the source.
⭕ Embedding Testers in the Team: Instead of a separate QA team acting as a safety net, have testers work alongside developers to guide testing from day one.
⭕ Continuous Feedback Loops: The faster issues are caught, the lower the cost of fixing them. Real-time feedback through automated pipelines prevents surprises down the line.
Final Thoughts
The Peltzman Effect teaches us that safety measures don’t always lead to safer outcomes. In software development, a dedicated QA team can create a false sense of security, leading developers to take shortcuts and rely on testers to catch defects. The result? More risk, not less.
The best safety measure isn’t a separate QA team—it’s a culture where quality is owned by the whole team. When developers take responsibility for testing their own work, defects decrease, collaboration improves, and software quality actually goes up.
So instead of throwing testing over the wall, let’s break the cycle and build quality in from the start.
