I recently made the argument (successfully?) that computers automate by nature; that anyone who uses a computer is by definition an automation engineer. Couple that with the observation that humans are always "testing something", and one could suggest that anyone who uses a computer is a test automation engineer.
For example, the Internet is automation of data retrieval, one that is engineered based on how we use it. My parents would not immediately identify weather widgets on Google as test automation. They just want to know if they need an umbrella when they go out. I, however, see a dashboard that allows them to interpret important data relevant to their needs and allows them to make decisions based upon their interpretation of that data.
Did they program it? Well, yes and no. While they did not sit down and write the statements that brought this convenience into their lives, they did set its preferences, position where they deemed fit, and ensured that it welcomes them with each new visit. Without these interfaces, the tool is of less use to them.
Another example: spreadsheets help automate data manipulation and presentation. My wife would not immediately identify a budget workbook as test automation. She would see it more of a way to track income and expenses, and how to identify if we're on target this month, can we go on vacation, etc. I, however, see it as a tool that allows us to repeatedly take all our disparate financial activity and produce a cohesive picture that allows us to manage our money better - to make better decisions (or to know the precise value of regret).
Did we program it? Well, yes and no. While we did not sit down and write Excel, we did set set up its inputs and its formulas using the interfaces exposed to us.
The differences between my definition and what is typically identified as test automation engineering have to do with complexity and intention - the scope of our solutions and how aware we are that testing/automating is going on in the first place. Like regular users, we manipulate the interfaces available to us in order to obtain data, arrange it into meaningful statements, test those statements for validity, and make decisions based upon those tests. Where we differ is how aware we are of the interfaces available to us, and how extensively we use them in our tasks.
One side note: neither of the tools used in the my examples actually automate information. That is the sole purview of people - to identify patterns and meanings. These tools may re-organize the underlying data, but we are the ones who are burdened with determining if this stuff makes sense or not; if it is valuable or not.
Hopefully you get my gist: we all use computers to automate tasks that are important to us. We all use more automation tools than we realize. We know more than we think we do, and do ourselves a disservice if we believe that the high-priests of automation are the only people worthy enough to discuss its doctrine.
Wednesday, May 30, 2012
Tuesday, May 22, 2012
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.
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.
Subscribe to:
Posts (Atom)
Posts
