"We Don't Need Testers" - what's your take?

Two jobs ago, I joined as the first ever tester to a team that had 20+ years of development without testers behind them. They hired me because they had figured out that when they log big visible error messages, almost 18 percent of use after login result in one and were puzzled on what the users do. It took me a year to get them to 0.1% but also teach the developers that they did know what was causing those, holding space pairing with them while they’d just look at me for confirming they would be doing the right thing - which they did not do without me reminding them at first. After 4 years at the company, I was still the only tester but the developers now knew how to test.

In this job I do now, with my previous team, I felt a bit of a deja vu going back to the idea that developers don’t test. They didn’t because they believed they were too valuable to pick up their own trash, and instead of sticking around garbage collecting, they are now again without a tester and management guidance on expecting things to be different. I had to step away to stop being their excuse.

Meanwhile, another team next door does brilliant without a tester and takes ideas from me on how they could improve their testing on our virtual hallways.

So my take is that teams are different and for many teams, having a tester makes them worse.


You quoted employee satisfaction,what about the customer satisfaction?


I think this can play a part but honestly I think there is more to it then this.

Modern software requires a huge amount of reliance on “other people’s code”. And it’s a challenge for any one person to fully understand every interaction.

This could come from third party libraries and layers of dependencies, frameworks and integrations with 3rd party systems.

Add on top of that modern software is usually a collection of loosely or tightly coupled services connected by layers of glue such as queues, gateway’s and load balancers.

In my experience, the code I receive from developers, at some level of isolation is excellent. It’s only when it comes to more complete integration or staging environments that issues present themselves. Of course this is because the developers I work with DO lots of testing. So I get to focus on the bigger picture and automated system tests.



The levels of dependencies that we have in today’s software prohibits any one person from completely testing (because of lack of time) the complexities involved, and it needs dedicated people out-of-the-box to take a look and devise strategies to check and test.

1 Like

Because the HR I spoke with was going ga-ga about how great their company is, I didn’t want to intervene and ask about product quality. Being a big end-user focused company, I presumed that their customers are pretty satisfied with what they have, otherwise the team would have had a different strategy in all these years. We should give that to them.

1 Like

That’s the problem you would have when you have one or two testers just for name sake and shift all the Quality responsibility to the testers. Everyone should be mindful of Quality and take care of their responsibility.

Having said that, not having any tester in the team is the other extreme where you won’t have anyone looking at the product out of the box. That’s not good given the complexity of today’s software.

It looks like being the only tester in the team and telling them how to do stuff ended up like spoon-feeding in the scenario you just mentioned. One of the perils of ‘teaching developers how to test’! Instead, file away bugs and let them take care of the issues.

At the end of the day, agree that organisational culture matters.

I think that we as testers are some part of the problem that we even have this discussion.

From my point of view the HR alwaysa hear “If test is late, a developer can help out”. You will never hear the opposite “Development is struggeling, let som etesters help out with development”.
So with that said it seams like if you have a whole team of developers they can do both…

And that goes also to the conference for testing, they have a program that covers all different parts of testing, It should cover test management to test automation to manual testing of an interface and write test in python or some other language.
You will nevere see a developers conference that covers more then one specific topic. I guess no one will attend a conference that cover, Java, .NET, Oracle DB, Python, R-language and MariaDB. That is to many topics to get focus on something.

So to change this I think the test commuinty must be better in telling HR and other what testers actually do and what they bring to the table. If not we will end up with this discussion forever.
We need to spread this outside the testering community, we all know why and what we do but do we share that and inform others about it. And also if we get more specific conferences and so on, that we can tell our bosses that we would like too attend then I think it will also be easier to get acknoledge.



Like some have pointed out before, each team is different. “Tester” doesn’t need to be a different person on the team. It is a role that can be played by devs/BAs/POs/PMs. What I’d be worried about is when no plays this “tester” role OR even worse when teams don’t have anyone looking at the overall quality of the product.


One other advantage of not having testers as a separate title is also that you’re just another engineer on the team, likely meaning you’re on the same pay scale/comp schedule as any other engineer.


In our small company, everybody on the dev team doubles as a tester. I coordinate the whole process, and I’m also the Customer Support Lead. That means that I have extensive knowledge of how clients use the product, which I can use to inform what we test and how to know if it passes. The devs do code review before anything gets to testers, and then we have a Product Review phase of testing when the junior devs and the designer and I test each story/fix before code freeze. After that, I put everybody on regression testing, in various areas of the program, based on the risks we’ve identified for the release.

The downside is that it takes a lot of developer time away from making new stuff, but the upside is that everybody is writing better code because they see what happens when they don’t!


If someone says they don’t need testers, and you don’t have the time to explain it to them, then you can let James Bach do some of the hard work on your behalf. It might or might not convince them. But hope for the best. Check out his talk -

What do you think?

1 Like