I accidentally started my career creating tools for testers. Right out of grad school, I was hired by a telecom company. They wanted someone who had experience with C++ and parser development; I wanted a job that matched my skills so this was a good fit. I didn’t realize it at the time, but I’d just been hired into a test automation team. Our team wasn’t called a test automation team per se; we were called a test tools team. Eventually, we started creating tools to help developers with testing as well, thus we were renamed a “tools team”. As a side note, there were politics involved as well (I know, weird, right?).

Thinking back to those “before times”, it dawns on me that some of what we created was used for non-traditional automation. For example, one of these tools allowed us to send and receive telephony protocol messages; we could even generate “test scripts” that could be executed as traditional test script-based automation. As a point of reference, you can think of this specific application as a very early, telephony-specific, API testing tool similar to the ones we have today. This was rather early in my career, so I didn’t think about traditional vs. non-traditional automation. To me, it was all just tools of some type or another and I just wanted to help people get their jobs done. Oh, and write code; I wanted to write lots and lots of code, but I digress…

When I talk about traditional test automation, I’m referring to what the industry simply calls test automation: automation derived from test cases that we usually turn into test scripts using some tool. That is, however, only one implementation of automation. At the risk of hubris for quoting my own blog post, a broader definition of automation gives us a wide range of opportunities with which to provide value in our testing organizations. The broad definition allows us to think of automation less in terms of test cases and test scripts and more in terms of applying technology to help testers do their jobs. Instead of the narrower concept of traditional test automation, we can think of providing help or assisting testers. This gives us the concept of automation assist.

Automation assist is just that: automation that assists humans who, in our case, are testers. It’s less focused on replacing human execution of tests and more focused on replacing human execution of tasks for which computers are better suited. It’s a term that Mas Kono and I coined during our time at an e-comm company. One way to think of automation assist is “automated crank turning”. Serendipitously, to me at least, automation assist has commonalities with facets of High-Volume Automated Testing (HiVAT), but that’s another show.

Some examples of automation assist that my teams and I have created over the years:

  • Aforementioned protocol message app
  • Random Clicker – These apps randomly clicked web page “clickables” looking for things that are “weird”, i.e. outside the specified heuristics. Reports are created for testers to evaluate after execution; the testers decide if there is an issue or not.
  • Account creator – This app creates accounts in pre-production environments, reducing the opportunity cost for testers.
  • Context-sensitive value replacer – Take hundreds of files and replace specific values but only specific sub-sections of the files; handling deep-nested context-sensitivity is something that computers are good at, but humans aren’t. Again, this reduced the opportunity cost for the testers but also took significantly less time and less effort to perform.

Each of these tools provided some value to a testing team even though none of these tools were based on test cases.

Come to think of it, my first semi-professional application was essentially an automation assist application. I previously set the WABAC machine and wrote of my time at the Oak Ridge National Laboratory, hence the reason for reusing “WABAC” in this post’s title. While there, the application I created as my major project was for helping diagnose issues with rotatory equipment. Notice I didn’t say “for diagnosing” because the application didn’t diagnose. The application assisted humans in narrowing down the area in the equipment that the problem likely occurred, but it was up to those humans to actually find the issue. I had no idea at the time, but this was an automation assist application. Sometimes you find parallels in unexpected places.

Returning to the subjects of automation and testing, the designation of a specific implementation of test automation as traditional or non-traditional is not the point here; certainly, there will be tools that straddle that line. Having new terminology to describe new concepts, however, can be helpful when taking advantage of the broader definition of automation.

Like this? Catch me at an upcoming event!