Do you have to be a programmer to write automated tests? By Andre Vondran

I was recently asked an intriguing question. The question was simple: do you have to be a programmer to write automated tests? But I struggled a bit to answer the question because to me the answer is not as simple as yes or no.
But I have a feeling that well-considered thought to the question is at the heart of what happens to the future of automated testing.

Many career testers are feeling the pressure of picking up ‘automated testing’ skills in today’s job market because every IT company wants it. On the one hand, it’s not fair to put someone into the position of architecting and building or even maintaining an automated test system without having any education\understanding of the sound programming skills and practices that are necessary.
On the other hand, why would anyone with good programming skills choose to enter into the thankless, dead-end, glass-domed, low-paying and under-respected testing career path? Let’s be honest, they wouldn’t unless they recognized it as an entry point into a much more lucrative development career path.
The latter is exactly the reason multi-billion dollar corporations have recognized that there’s a huge market in creating easy to use automated test tools that require special skills to operate but no programming is necessary to be up and running and fairly successful in a short period of time. I think mercury, silktest and IBM haven’t done us any favors though. They’re marketing these ‘record-and-playback’ tools (in a way that’s reminiscent of Sun Microsystems early Java marketing) as entry level tools and creating a misperception in the market-place that deep technical knowledge and understanding of software systems is not necessary for automated testing.

It sounds as if I’m leaning strongly towards a ‘yes you pretty much do have to be a programmer to write automated tests.’ doesn’t it? So this is where my brain starts to spin in circles as I contemplate the paradox we’re in. If you think about it, automated testing is right now about where we were in 1995 with web application development. (And yes I am actually old enough to speak from experience about that).
There was a tremendous amount of buzz around then as people started realizing the potential of the World Wide Web and anyone who knew a few lines of HTML got hired. But as the requirements got more complicated, so did the systems and the crappy beginner code that people were writing to get stuff out fast started to crumble. Now people are much smarter about hiring for the necessary skills. I think we’re starting to see a little of that backlash with automated testing, as a few progressive companies start thinking a bit more carefully about the skills that are needed to do it properly, but the industry hasn’t reached the moment of truth yet.
Partly because, there truly aren’t enough people with expert-level experience to get us to that moment.
So given all that, how do we solve the problem of creating the right balance between automated testing and strategic testing and how do we define the set of skills needed for the testing industry to move forward?
Well, let me say that firstly that a few of those people who got hired because they knew a few lines of HTML turned into really excellent programmers.
Correspondingly some of the automated test developers out there are also turning into really excellent programmers and are thinking about the right things when it comes to architecting an efficient automated test system.
I believe automated testing has absolutely tremendous potential and we haven’t even cracked the egg yet. There are so many frontiers to explore in this arena such as artificial intelligence, service-oriented testing, intelligent dimensional data analysis…the list goes on.
So how do we convince the bright, talented innovative thinkers in IT that automation can be a destination too, not just a path to another better job? I really don’t know any quick answers as the problem is a systemic one and touches on the mindset of the whole industry.

My two big suggestions are to:
1. Raise the bar in how we define the skillset needed to do this work and realize that an automated test developer is actually a programmer
2. Open up research and development projects that make automated testing a destination instead of a half-way house.