When hiring software testers doesn't work (and what to do BEFORE you hire them)
I saw a LinkedIn post recently that got me thinking. A recruiter shared a conversation with a startup CEO who argued that software testers “cause more harm than good” when you factor in cost versus benefit. Long story short: he said that if you hire strong developers with quality mindsets, you don't need people in dedicated quality roles. And honestly? That’s not entirely wrong...
Now, before I lose my MoT membership card, I want to be clear: I’m not saying that quality work doesn't matter. It absolutely does! However, some teams simply don't need dedicated quality hires. If you're early-stage, have a simple product, and your engineers are genuinely quality-minded, adding a dedicated tester might just slow you down.
But I've also seen the flip side. I've been a solo tester three times now (which I wrote about here), and I've helped teams make similar hires from the other side. For example, a few years ago, a friend asked me to help his startup with their quality challenges. “Honestly, if we could just get our regression tests automated, our releases would be so much smoother,” he told me as he showed me around their small office space, rented from a coworking company.
His company ultimately didn't make it. (Most startups don't survive, even those with no quality issues.) But that conversation stands out to me now because it’s such a perfect example of what I've seen over and over: teams believe they need to hire someone to solve "a testing problem" when the real problem is something quite different. And in the end, because they hired someone to solve a symptom rather than a cause, teams conclude that "software testing doesn't work."
