Some perspective on testing 'trends'

This blog post was published earlier in my (now defunct) weekly newsletter on January 31, 2023.

Every year, often around the beginning of the year, I see the same phenomenon: people talking about trends and predictions about where the testing and automation world is headed, and what people and organizations should focus on in the year to come.

Now, I’ve been active in the testing and automation space for a while now, and at the risk of coming off as a grumpy old man (and depending on who you ask, you might not be too far from the truth..), personally I don’t see much value in these predictions. I certainly stopped paying attention to them a while ago.

Instead, in this newsletter, I wanted to share with you some of the perspectives I’ve gained over the last 16 years, referring to what people may consider trends, but what I think is much more a natural evolution of the way we write and test software.

Claims of software testing being dead

I’m probably preaching to the choir here, but as you know, software testing is far from dead. It is changing, of course, but then again, the whole software world is changing. It would be ridiculously naive to assume that testing is somehow immune to this. Our roles evolve, testing evolves, but as long as we’re creating software, we’ll probably have a need for people who can assess a product, challenge decisions, be the voice of reason and/or concern and advocate for quality. Guess what?

That’s what testing is.

The way in which we perform our work is changing, though. We no longer wait until development throws software over the wall. We don’t spend ages just writing test plans, creating test cases and executing them. We might do some of that, but in a much more short-cycled and collaborative way than we did when I entered the testing space in 2006.

By the way, here’s a great response to / explanation of James Whittaker’s infamous ‘Testing is dead’ talk by Alan Page. Written almost 10 years ago, but lots of things in there are still highly relevant.

Claims of automation and AI replacing software testing

We’ve all seen this, and we all know it’s not going to happen, at least not anytime soon. There’s a lot that modern software testers do that simply cannot be replaced by automation. Asking questions. Challenging designs. Bringing up ethics. And those are just some of the examples. Sure, automation can be really valuable in supporting the software testing and development process, but they don’t replace testing.

The same applies to AI developments like GitHub Copilot and ChatGPT. They will not replace developers, nor will they replace software testers. That doesn’t mean we need to discard these applications, far from it. I think it’s important, though, to learn how to use AI to your benefit and make you a more valuable and productive tester or developer. If you don’t, someone else will, and guess who they’re going to pick when your CV competes with their for your next job?

For both automation and AI, it’s important to remember the following: they can and should be used to support you, but they’re not going to replace you.

Running after the latest tools

Tools come and go. When I started out in automation, we mainly used TestPartner and later QuickTest Professional. Later on, that shifted to Selenium WebDriver. These days, I see a lot of demand for Cypress and Playwright. By the time you’ve finished reading this newsletter, some new tool will probably have been released, claiming to replace the established ones.

In my early days, I spent a lot of time learning the latest tools, trying to stay on top of all of them. Nowadays? Not so much anymore. Why? Because in their essence, all these tools do the same thing. UI automation tools and libraries help you find elements and interact with them. API automation tools and libraries help you create and send requests and parse and inspect responses. Unit testing frameworks provide test runners, assertions libraries and some basic reporting features. And so on.

In other words, new tools typically do the same thing as their predecessors, maybe in a slightly different way. Learning all of them, and even worse, debating which one is ‘better’ or even ‘the best’, is a pointless waste of time if you’d ask me.

Instead, these days I spend much more time honing more fundamental skills, both in software testing and in automation / software development. I’ve come to realize that it’s these skills that make you stand out from the herd, not knowing everything there is to know about the new tool kid on the block. Also, these skills typically last a lot longer.

As I tend to put it: principles and patterns over tools and tricks.

There are very few tools who have really changed the way I look at testing and automation in the last couple of works. The only one I can think of is maybe contract testing, but other than that, most new tools are just providing different ways to do the same thing we’ve been doing for ages.

These are just three of the things I’ve started to notice ever since I started my career in software testing. A lot has changed since then, but then again, nothing has changed all that much. I see no reason for assuming that the next 16 years will be significantly different.