Not All Engineering Teams Need Testers
But Every Team Needs Testing
Here’s an unpopular opinion: not all engineering teams need testers. This is a polarizing statement because there are two distinct camps:
The testers—who strongly believe that every engineering team should have a dedicated tester.
The skeptics—engineers and leaders who argue that testers are unnecessary (some even claim testers hinder development).
As a consultant and startup advisor, I’ve had countless conversations on both sides of this debate. And the truth is both perspectives have valid points.
Before you assume I’m sitting on the fence, let me be clear: I am a tester at heart. I understand why testers advocate for their role on every engineering team. I believe most teams would benefit from an experienced tester who brings a mix of critical thinking and technical expertise.
But here’s where the argument for testers on every team breaks down.
When a Tester Might Not Be Necessary
There are a few key scenarios where embedding a tester in an engineering team isn’t a must:
Not all testers bring the same value – A highly skilled, technical tester can be a game-changer. However, if a tester lacks technical depth or strong critical thinking, their contributions may not be enough to justify the role. This is one of the primary concerns raised by the “no testers needed” camp.
Small, scrappy startups operate differently – In the early days, everyone is responsible for testing. The priority isn’t catching every single bug—it’s shipping fast and iterating. In these early days, systems are usually simpler with fewer interfaces, making testing more manageable. Some don’t even have customers yet, or they’re in beta, where a higher tolerance for bugs is acceptable.
The Case for Dedicated Testers
On the other side of the debate, some engineers and leaders argue that having a dedicated testing function is not only unnecessary but counterproductive—suggesting that testers could make engineers complacent.
This perspective assumes that if testers exist, engineers will "slack off" and leave quality concerns to them. Some even point to Google and Facebook as examples of companies that operate without dedicated testers in some of their teams.
But this argument is flawed for a couple of reasons:
1 - Developers don’t “slack off” just because testers exist
Testers and engineers are partners in building quality software, not separate entities working in silos. When testers are embedded in teams, they don’t exist to catch developers' mistakes—they collaborate to prevent defects and enhance code quality together proactively.
Rather than viewing quality as something that can be “offloaded” to a single role, the most effective teams share responsibility by integrating testing practices early in development. For example:
Pair programming and code reviews – Testers can collaborate with engineers to spot potential edge cases and improve testability before merging code.
Shift-left testing strategies – Teams can implement unit tests, API contract tests, and static analysis as part of the CI/CD pipeline to catch issues sooner.
Exploratory testing alongside developers – Testers and engineers work together to uncover usability and integration issues before they reach production.
Monitoring and observability – By designing better logging, alerts, and user analytics, testers, and engineers can detect anomalies early and respond faster.
Bugs don’t happen because developers are careless—they occur because modern software systems are inherently complex. By fostering a culture of collaboration, shared ownership, and early defect detection, engineering teams can build more resilient, high-quality software together.
2- Companies like Google and Facebook are unique cases
While it’s true that some teams at these companies don’t have dedicated testers, it’s important to consider a few of the reasons why:
Their software is free, and they can afford to rely on user feedback for bug discovery.
They have millions of users, so they can roll out features to a fraction of their audience first, catching issues via monitoring before full deployment.
Unlike banks, healthcare platforms, or financial services, their products don’t handle critical user data where failure has serious consequences.
For companies in regulated industries, where a bug could cost money, impact health, or damage reputation, testing cannot be an afterthought.
When You Might Need a Dedicated Tester
Here’s a simple way to think about it:
✅ You may not need a tester if:
Your software is free, and minor bugs won’t impact credibility.
You have strong monitoring and observability to detect issues in production.
You’re in the early stages of development, and speed matters more than perfection.
🚨 You likely want to have a tester if:
Bugs in production could impact customer trust, finances, or safety.
Your software is used in high-stakes industries (e.g., healthcare, banking).
You want to prevent costly failures rather than reactively fix them proactively.
Understanding this distinction is key to making informed decisions about testing roles in your engineering teams. The answer isn’t black and white—it’s all about context.
Now, I’d love to hear your thoughts! Do you think every engineering team should have a tester? Drop a comment, and let’s discuss.
That's a really interesting topic, Alessandra, thank you for bringing it up.
I think there are many opinions here and many, very different experiences. I have definitely seen a lot of crappy products that are being testing by decimated testing teams. And I've seen high quality software that was never touched by a professional.
My personal background is that I started my career (as a developer) surrounded by tested. We had major quality issues. The testers were a mixture of very skilled engineers and also some that could just click around and write tickets. There, I think the majority of bug was actually known by the test team, but it was a managerial decision to sleep them under the rug or downplay them. After that, for many, many years, I was involved in mostly startups where we couldn't afford to have dedicated tested. And the quality was always quite good.
I think, in the majority of cases, there's a causality vs. correlation issue. Teams that have testers and also underperform intersect quite a lot, but that doesn't mean that the testers caused it.
Often times, the decisive factor is not testing vs. not testing. It's social dynamic. People either care and are careful, or quite the opposite. You could hire testers if they don't, but people will still not care.
With the rise of concept like the DevOps methodology, more emphasis is put on engineering teams running their code on production. The same could be applied to testing. Ensuring quality IS part of development. A testing team can improve quality or make testing more structured. But it does NOT mean you are no longer responsible for the quality of what gets released.
Also where regulatory and compliance burden is huge like telecom and banking. In case of without domain and specifications knowledge difficult for any developer to test the application. Even integation challenge also huge in telecom. Multiple products from different companies integrated and tested.