Why Testers (Probably) Shouldn’t Be Writing Test Automation

A bit of personal context

Last week at work we received the feedback from the appraisals that have been carried out over the past few months. The appraisal process consisted of gathering feedback from a few of my colleagues, and then that was processed by my manager, fed back to me, and was also used to calculate my bonus. Across the board, I received really positive feedback, and it was lovely to hear that my colleagues were happy with the job I’ve been doing.

Part of the feedback was the ‘Where could they improve?’ section, which is often the most interesting, and often the place I look to see where I can improve and grow in my role. Normally it’s quite varied, sometimes specific to the relationship I’ve built, or sometimes even lack of relationship built with the individuals.

This time though, there was really only one theme, and it spanned across all of the feedback; test automation. I didn’t do enough of it, I didn’t ‘own it’ enough, I’m not doing enough to learn more about it, etc. My manager agreed and tried to discuss the steps we could take towards me learning automation.

Now, if I applied for this job on the back of my automation experience, I’d completely understand the feedback. The problem I have is that I didn’t. In fact, I’d say the opposite. The company already had some very talented testers that are very good at test automation, so I was brought in on the back of my 11 plus years experience as a specialist in user-centric exploratory testing.

I was seething after hearing this feedback, to the point where a younger me would have walked out there and never come back. My manager tried to say comforting things but effectively only insulted me further by suggesting that it’ll strengthen my CV, as if my skillset is somehow lacking because I don’t have this one specialist skill he deems more valuable over all the ones I’ve spent over a decade learning and refining.

The automation myth

Unfortunately, this isn’t just an issue with my team. This is an industry problem that’s currently damaging the wider testing community. I’ve come across it in nearly every job I’ve had, and it’s a problem I can’t see going away any time soon.

The myth goes that automated testing can replace manual testing, and that it will.

Much has been written on the topic of why testing can’t be automated, but if you want to read more, I’d suggest Googling ‘testing vs checking’ and reading any of the well thought out blogs on this topic. The key takeaway is that you can’t automate testing, you can only automate checking.

Despite all of this though, there is still so much pressure on testers to learn automation. Nearly every job spec mentions some form of automation, and even when it isn’t, there is often an assumption made that a tester wants to learn it, or just should learn it.

Automation is still valuable

Just in case this is starting to sound like an anti-automation rant, it really isn’t. Automated tests are extremely valuable when maintaining high-quality software. From unit tests up to automated UI suites, they all have their place and value, and every development project should have the relevant automation in place at the relevant level.

The issue is that 95% of the time, testers are the wrong people to be writing them.

Who should be writing automated tests?

Without over-simplifying this too much, the people who should be writing automated tests are the people who write code for a living, the people who have trained for years to understand what the code they write does, what makes good code, and understand how it could be refactored and improved.

It shouldn’t be the job of someone who’s just done a four-hour course on Pluralsight or someone who is “giving it a go” in-between other tasks.

Sometimes it is a tester who is best placed to do it. As mentioned earlier, I’m fortunate to work with some testers that are very experienced and talented at writing automated tests, and it is clear from working with them that they are definitely qualified to be doing so.

Most of the time though, it’s the developers on the team that are best equipped to work on the automated tests, because they’re the ones with the coding ability and experience. They would likely do the work 10 times faster than someone who’s “trying to do automation”, and the code will probably be 10 times better.

The extra benefit of this is that if the developers are heavily involved in writing the automation, they are then invested, and it means the automation will be maintained. Too often a tester owns all of the automation and the moment they leave, the suite is abandoned because no-one has any investment, or if anyone does try to maintain it, they realise how poorly the code is written, and start again.

Why is the expectation often on testers then?

From conversations I’ve had with both developers and testers, there are two main factors that perpetuate the perception that testers should be writing test automation:

1. Developers enjoy writing software a lot more than writing tests, so would rather someone else do it.
2. Testers are made to feel like they aren’t good enough unless they can write automated tests, so they feel like they have to take on the work in order to prove their worth.

This combination has created the damaging culture that has not only caused lots of poor quality automation to be written, but it has also caused lots of testers to be looked down on because they choose to focus on other specialisms, or simply for not focusing on this one.

Concluding thoughts

In most cases, testers can provide so much more value focusing on other areas, and often they will have their own interests or specialisms that are overlooked because decision-makers believe in a mythical test automation silver bullet.

They continue trying to hammer square pegs into round holes like a frustrated infant, instead of taking a logical view of the situation and encouraging their team members to play to their strengths instead of their weaknesses.

This view that testers are inadequate because they can’t, won’t, or simply don’t want to learn test automation is a toxic cloud hanging over an otherwise forward-thinking testing industry, and the sooner we abandon it, the better.