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