Test Automation

Note: I'm writing this in the true hope that, within my lifetime, time travel will become a reality. And that future me, given to indulge in the kinds of preoccupations beset upon the nouevau riche, will visit past me with this post firmly in hand. I look forward to the chastisement that I gave myself 3 years ago.


Warning: It is a bit complain-y.


Example #1: I watched my niece fumble through some math problems. In her concentration, she utilized humanity's greatest aide to the mind addled with numerical perplexity: she counted on her fingers.

We have these fingers. But we also have the abacus, calculators, Babbage's adding machine, personal computers, cell phones, etc. We have a lot of ways to solve the problem of '2+2', and yet we still count.

We've automated the means, but the need remains.

Example #2: From papyrus to the the Gutenberg press - we like getting our message out. In recent years, the effort it takes to get a message out has become almost laughable. I am writing this blog post at home and will publish it to a medium that goes around the world instantly. Whether it is read....

We have these papers and pencils. But we also have blogs, Twitter, Facebook. We have lots of ways to solve the problem of 'how do I communicate this idea to others'; and, as evidenced by this post, we're in no shortage of opinions or things to say..

We've automated the means, but the need remains.

The point: the computer is a tool that automates tasks we've programmed it to do. Be it math problems or publishing daily drivel, it exists to make things easier by abstracting away all the gritty mechanics of it all. But we use it as a tool towards a greater end than just itself. What's left after our tools do their work is the thing we sought in the first place. My neice found her answer. My voice found its audience.

If you accept that point as valid, then you may see why I now think the obsession with test automation is ridiculous, especially when it wears itself as a badge of honor. We don't hear writers extol their prowess at automating words. We don't hear scientists happily exclaim that while they have not solved the problem at hand, they have several thousand lines of framework ready to log the stack trace of all their functional programming. It may be shocking for some to consider that computers are now so ubiquitous that everyone is a test automation engineer.

Perhaps I'm jaded, but this is partially why I stopped blogging about my journey in software testing. It is why I no longer darken the virtual door posts of the online watering holes wherein gather my former compatriots. The software testing I was enamoured with got stuck in a rut where the same functional test automation question repeated over and over ad infinitum. Don't get me wrong - I'm eternally grateful for all the help given to me when my voice rose in chorus with the din of noob-posts. I just fear that many newcomers now (continue to?) see this brand of "testing" as a means to be amazed at their own brilliance.

Experience taught me things ambituion could not. Software testing is not the problem that needs to be solved. Who hasn't felt the narcotic effect of basking in the glow of perceived efficiency? However, my current role requires me to manage the testing I used to automate, and to do so from the customer persepctive. It is here that I hear the echoes of my naivete resonating back across the years. Decisions I once thought dripping with the kind of genius that would cause the world to beat a path to my door now seem to be unnecessary complications. The fun was in writing all that code and dreaming of the time it would save. The hell is now in maintaining it, training to it, supporting it. Ugh.

Example #3: As an adolescent learning to play the drums, I gazed upon the massive arsenal of drums and cymbals that MTV served up daily. "This," I thought to myself, "is what playing the drums IS!". And so I asked Dad for a new cymbal. His response was, "learn to play what you've got". And so, 2 days later, I returned exclaiming that I had indeed learned to play what I had and was ready to receive my reward. He laughed and ignored my request. Now, years later, I know why.

Playing drums is hard. It's demanding. It's exhausting. It requires discipline and experience. Mistakes are mandatory avenues towards greater mastery. And so it is with software. So the next time I read someone wanting to know how to automate testing, I'm will fight the urge to respond, "learn to play what you've got".

But more than likely, I'll just ignore it. Before you think me cruel, you should hear me play drums.