Guess what? You're a developer

This post was published on May 11, 2023

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

I’ve said it before, plenty of people have said it before I did, and hopefully plenty of people will keep saying it after me:

“Test automation is software development.”

In and of itself, that’s true, but I feel that without context, it’s also somewhat of an empty statement. It looks good in a Tweet or a LinkedIn post, but that’s about it. Which is true of a lot of social media content in general, but I don’t want this to turn into a rant on social media and the quality, or the total lack of it, of the content on there. I’ll probably get to that another time.

Back to what I do want to talk about today. And that’s the feeling that not a lot of people really dive deeper into the consequences of test automation ‘being software development’. I touched on it a little in earlier blog posts, mainly on why I think it’s a good idea to learn a little more about fundamental programming principles.

Today, I want to explore the pithy statement that is ‘test automation is software development’ a little further, and more specifically, I want to talk about one of its implications. Because, if test automation is software development, it implies that when you’re working on writing test automation, you are a software developer.

Yes, you read that right. You. Are. A. Software. Developer.

Now, before you all go and start updating your LinkedIn profiles, think a little bit about what that means, being a software developer.

It means you probably should be comfortable using a wide range of tools and libraries, and knowing when to apply which one of them. You wouldn’t hire a developer whose suggested solution to all problems was to build yet another Spring microservice, right? Sometimes, you’ll simply need a different tool or library. The same goes for automation: not every problem is best solved with Cypress (or Selenium, or Playwright, before we get into that discussion again…)

It means having working knowledge of other tools that play a role in promoting code from a laptop to production. Version control, CI/CD pipelines and containerization technologies come to mind here. I would be hesitant hiring a developer who wrote the most brilliant code and then responds with a blank stare when you ask them to make that code a working part of a release. The same applies to test automation: no matter how brilliant your tests are, they’re worthless until they’re running on demand, on someone else’s machine. Do you have what it takes to get your tests there?

It means you’ll need to start learning how to do all those other things you expect developers to do. Pair programming. Contribute to design and architecture discussions (including testability and observability, anyone?). Test your code before you commit it. Yes, you read that last one right. Your test code is code, and it should therefore be tested, too. We’re very good at complaining about developers not doing enough testing, but how many of us can honestly say they properly test their own test code?

Oh, and before you start to wonder: all of this applies to those of you using low code tools for their automation purposes, too. Using low code tools doesn’t make automation any less a form of development, you’re just choosing to use yet another abstraction layer. It’s still code. And in the end, it’s all software, and should therefore be treated as such.

And the list goes on. I’ve already briefly mentioned fundamental (object-oriented) programming skills, for example. But it doesn’t stop there, either.

Yes, I know that learning all of the above skills requires a significant investment for those of you looking to break into test automation, or to grow as a test automation engineer. And this all comes next to, not instead of, growing and honing your software testing skills. I never said that this was going to be easy. As a test automation engineer, you’ll (probably forever) be in that universal split between software testing and software development.

And the ‘test automation is software development’ has implications for teams and organizations hiring for test automation engineers as well. Whenever I speak with companies looking to grow their skill set, I ask them if they know what they’re looking for. Typically, they’ll say ‘someone with 3-5 years of experience in Selenium (or Cypress, or Playwright, … damn this gets tiring!) and Java’. What they often don’t realize, is that knowing those tools and languages alone don’t make a good automation engineer. As I’ve tried to stress in this newsletter, it takes a lot of more fundamental development skills, too. Something to think about for those of you trying to hire automation engineers!

So, wrapping this up, if you want to be, become, or hire a valuable and versatile test automation engineer, it might be wise to start thinking of yourself or them as a software developer, too.

As always, I’d love to hear your thoughts.

"