No, Really, What Is Automation?

Thoughts on traditional automation and automation assist

By Paul Grizzaffi, Principle Automation Architect, Cognizant Softvision

As I do from time to time, I recently (re)posted this to my LinkedIn and Twitter…

As often happens, Michael Bolton posted the following comment…

After a cavalier opening statement, as I am wont to do, I answered his question in earnest. The following is the distilled version of my replies. I chose to turn them into a blog post so people could more easily read it, I’d have it in one convenient place for when I need to refer to it in the future. If you want to see the full interaction, check it out on LinkedIn.

In my broad context, automation means a judicious application of technology to help people do their jobs. The people that I’m typically helping are testers and those performing testing-related activities. The central idea of this definition is “let’s use machines to help humans be more effective and/or more efficient at their jobs.”

What forms could this “help” take? Here are a few:

• Scripts to help with creating or inputting data
• Scripts to execute specific actions after each software build
• Scripts to execute specific actions at certain times or intervals
• Scripts to exercise various portions of an app, looking for events or states that fall outside of specified heuristics
• Scripts to perform complex calculations or comparisons for which machines are well suited (and humans are not)

Some of the scripts could be classified as what’s traditionally called “test automation,” i.e. scripts that are derived from test cases and typically have a pass/fail result; others are what I’d consider automation assist, automation assist being those scripts that assist the tester in non-traditional ways. Often, these scripts don’t result in a pass/fail result; these scripts are typically more about “turning the crank” of the application by performing routine tasks for which computers are well suited such as data entry, mathematics, or rote button-pushing.

Instead of making a distinction between traditional automation and automation assist, couldn’t it all just be called automation assist? Or automation in testing? Or just testing? Certainly, however, Michael and I previously had a discussion about High-Volume Automated Testing (HiVAT). His position, at the time, was that it should really be called High-Volume Automated Checking; my response was that calling it by a less-familiar and less-searchable name would make the documentation on HiVAT harder to locate.

It’s like when I, as a consultant, engage with people I’m trying to help. Calling tools, technologies, and concepts by names with which people are not familiar can increase the ramp-up time for making progress. Calling those tings by the names with which people are familiar, can give those people some comfort during a change process that is likely to be uncomfortable anyway. I then add new terminology for “new” approaches/techniques to distinguish.

To touch on the tweet’s aforementioned point of automation development, why should we consider all this as “software development”? Because in almost every case, it is. When we write testing scripts using a traditional programming language like C#, Python, etc., we are creating software to help us do our jobs. As such, there are many activities in which we engage when developing software, such as:

• planning
• design
• review
• testing
• debugging
• storage

Even when we use a record-and-playback, record-and-generate, or drag-and-drop tool, we are sequencing steps to be used later; those steps are essentially programming. They produce an artifact that probably should be stored and version controlled, just like “hand-coded” software. They produce results that possibly need to be stored and that should be reviewed for correctness-vs-expectation and appropriateness (maintainability, readability, brittleness) just like “hand-coded” software. Don’t discount this approach to automation as non-development simply because you’re not directly exposed to the underlying syntax.

Get more insights from our engineering and design experts on our website!