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.
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.
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.
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 -
