If You Want to Write Code, Be a Developer

One Rung at a Time

I’ve both seen and have read about QA automation being a step toward becoming a developer. Of all the automated testers I’ve worked with, it’s been about… 60% of them going on to become devs. A large part of the rest are pretty good at slinging code and could easily make the switch if they wanted.

For me, I went the opposite direction–I was a developer for embedded projects for a couple years after college, and actually fell into testing and automation. The first job where I started in QA, automation was the only option. Learning about the art of actually testing and test strategy came later.

Here’s what I’ve learned from seeing both sides.

Apples and Oranges

It’s easy to imagine that production code and automation code are the same. But from what I’ve seen, it’s not.

Don’t get me wrong, I mean, they’re both code. But the main differences lie in what the code’s meant to accomplish.

Production code (the stuff developers write) is a translation of business logic into something a computer can understand.

Test automation code is a translation of tester logic, or test cases, into something that checks to see if the developers implemented the business requirements correctly, and, allow a path for the testers to think of things that nobody else did.

The focus of the developer is the code, but the focus of the tester/automator is testing of the code. Because automation has more layers of abstraction on top, there are some patterns that work great in production code that aren’t so great in test automation code.

For example (blasphemy alert): things like inheritance and polymorphism are more harm than good in test automation. Every time I’ve seen it used, it takes the focus off the app that we’re testing, and puts it squarely on the code itself.

So then more time is spent trying to figure out:


  • what class is supposed to be used,
  • how it extends/inherits from the base class(es),
  • whether that grouping of classes even has what you’re needing,
  • what methods to call within the class,
  • how to extend functionality if you find out what you need isn’t available yet, and,
  • a general need to understand a lot of deep/grungy stuff about the automation just to be able to use it.

I just want to click the Submit button on the current page.

Valuable Automation

If you interviewed for a job as an automation engineer, and were told that the goal was to be able to automate new tests without writing any new code, would that put you off?

If you answered yes, then I’ve got some bad news: that’s what we’re trending toward. The most valuable automation is the stuff that not only requires little-to-no code to write new tests, but also expands the audience of contributors, many of whom aren’t developers. So you may not get as good a code workout as you’re looking for if you’re looking to get deep into development via QA automation.

Because, as complicated as test automation can be, it’s really just to support some very basic operations. Clicking buttons. Getting text out of elements. Typing strings. Making SQL queries. Sending and receiving webservice payloads.

Although the right stack, and a lot of code are involved in making this happen, it doesn’t necessarily mean that any new code has to be written to create new automated tests.

The Heart Wants What It Wants

Listen, this isn’t supposed to be a rant against qa-to-dev transitions. A move is a move, and I encourage people to move as often as they can. I’m just saying though, if what you’re really after is a developer job, then I want to also encourage you to just go for it.

Because let’s be honest: If deep down you want to be a developer, is your heart really going to be in QA? Will stuff like testing, test strategy, logging bugs, quality advocacy and maintenance ring true for you? Or is it going to seem like a slog just to get to the fun part: automating tests?

In QA, that boring stuff is actually the meat and potatoes of that position. That’s the important stuff. If you know you will (or already) do hate that part of it, then… it’s kind of a disservice to the role, right?

Life’s too short to do work that you hate. So go for the dev job! 

How? Do some side projects. Build your portfolio. Contribute to open source. Go to meetups. Talk with people. Start a blog! Get your name out there so that people–and eventually managers–can equate your name and face with a skillset. And read, read, read. Become a sponge for information, and apply what you learn as quickly as you can.

Before long you’ll have the developer job you were looking for.

Go get it 🙂



2 thoughts on “If You Want to Write Code, Be a Developer

  1. Interesting thoughts, and I agree with most of it. Especially the part about ‘if you’re heart is in development, go be a developer’. The automation craft, like the testing craft as a whole, needs people that are in it for the right reasons, not just as a transition phase into something else. Someone who’s ‘just doing automation for a year or two’ before moving on to an (entry level) development job probably isn’t going to be really valuable to the craft. That’s OK for that person, and I won’t judge him or her for it, but if we’re looking to further development and mature the test automation craft as a whole, that’s not the type of people we’re looking for.

    This part, though, I find a little overly simplistic:

    “Because, as complicated as test automation can be, it’s really just to support some very basic operations. Clicking buttons. Getting text out of elements. Typing strings. Making SQL queries. Sending and receiving webservice payloads.”

    You can say the same thing about a lot of development activities. A lot of front end development (to me) is about the exact same thing, for example. So while your statement might be true, it’s also true for a lot of other types of development (and yes, test automation is a form of software development as well). No need to single out automation for this reason.

    Apart from that, great piece and an interesting viewpoint.


    1. I really like the comments about not treating test automation code the same way as we do development code. They are very different and while some code quality patterns ought to be applied to test code (and testers should be learning about good practices in code quality to see where they can apply it in their work), we should not blindly apply anything. I agree with your blasphemous statement. There are some coding constructs that should not be used in testing code. We need to be smart about automation and what it does and not just blindly apply ‘best practices.’


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s