It's not uncommon for organizations to use automation on a few projects and then realize automation is a lot of work. They want to get more out of the automation tool investment but with less development cost. By removing the word test from test automation, you liberate yourself to use the automation tool set in new and innovative ways.
Like many technologies, test automation comes with a lot of promise about what can "easily" be done. These tools generally take more effort than guaranteed during the sales presentation and typically yield less than desirable results, considering the time invested. The biggest reason for this problem is the disparity between what we’re told to use these tools for versus what their true capabilities are.
This is a perception I'd like to change.
Beyond Automating Tests and Test Cases
A number of years ago I was working for a large retail company in Plano, Texas. We developed a testing center of excellence and I was part of the test automation team. While we had developed dozens of automated testing solutions, it seemed our HP tool set was capable of so much more. Then an opportunity presented itself: An in-house project needed a number of transactions put through it on a regular basis. It dawned on me that we could use our test automation tool to perform the mindless task of entering dozens of transactions as needed for our development team. Because no validation was necessary, the automation was fairly quick to build and turned out to be extremely helpful. Additionally, it gave me a glimpse of what was possible if we simply removed the word test from test automation.
Years later, I've come to realize that removing the word test from test automation gives me huge advantages over many test automation engineers. I have the same tools they do but a much more open mindset about what I can do with those tools. This changed perception allows me to bring great advantages to my company and customers and squeeze significantly more capability out of my tool set. With this in mind, I would like to challenge you to adopt a similar way of thinking and begin referring to your test automation tools and test automation team as simply your automation tools and team. That is the first step in utilizing your tools and resources in ways you've never considered before.
Automated Transaction Entry
Identify repetitive tasks happening within your organization that could be automated. Remove the idea that you have to test something along the way; just consider repetitive things that happen on a regular basis and determine if you can automate them. Consider the N-Curve effect to ensure you pick opportunities that build upon themselves and are not significantly different from one another. Target automated transaction opportunities that can be completed within a few weeks and will be used every month, weekly, or even daily, if possible. Finding good wins in areas like these can free up talented people for greater creative opportunities.
Automated Data Validation
When working on a project a number of years ago I came across a single website containing more than ten thousand values to validate. Even the most determined test engineer would be fatigued when trying to validate a volume of data like this. Instead, we leveraged our automation tool to complete this task in less than an hour, freeing our testers to focus on more complex tasks.
Identify opportunities within your organization that have very repetitive tasks where manual testers only validate a small portion due to the scope and size of what ultimately needs to be validated. Consider areas where no user interface exists yet and your automation tool can make countless SQL calls to validate actual results against expected results.
Automated Environment Validation and Configuration
The capabilities of even the most basic automation tools will allow you to check for directories and files that exist on a local file system. With minimal additional effort, registry entries can be validated and even set. See if you can identify the parameters one would want to verify to make sure a testing or development environment are set up in a specific way. Because most automation tools can launch applications, it's possible to have the automation tool open multiple applications and ensure they are properly configured.
Automated System Monitoring
Have you ever considered that an extra PC lying around the office could be repurposed to monitor a variety of systems are online and working as expected? In addition to monitoring, the automation could email, text, or open a ticket with support services if something was determined to be down. There are other types of technologies that can do this, but if you're on a tight budget, already own automation software, and simply want an easy way to monitor things, an inexpensive PC doing this type of work could be a real lifesaver.
Automated Data Preparation and Setup
How often do you need unique test data? Consider the capabilities of your automation tool to generate test data for your organization as needed and in the specific formats and quantities. Seeding programmatic arrays with data and random number generators could lead to some very creative data generation capabilities. Combine the mathematical and string capabilities of your automation tools and you could generate addresses, ZIP codes, pricing, and tax data for all sorts of applications. Whether it's random data or data that follows a prescribed methodology, allowing your automation to be an effective tool for generating test data makes good sense.
A new technique I've started to use to identify automation opportunities—or AutoOpps, as I call them—is to schedule regular desk visits with our test engineers to learn what's eating their lunch. This has resulted in countless AutoOpps identified in just a few short months. Make sure to come up with a method to document the AutoOpps you identify so they can be evaluated regularly and developed as time allows. Regularly evaluate these AutoOpps for applicability to current challenges and leverage capabilities learned and developed in earlier AutoOpp development projects. Keep AutoOpp development to no more than two weeks of time per opportunity if possible.
Take time to step back and think outside the box of classic test automation. If you do, I'm certain you'll uncover great opportunities right under the surface of everyday life for the typical quality assurance engineer.
User Comments
Although I appreciate the intent of your message, and to some extent agree with it. I am just continually disapointed that we, as a profession, have to be somewhat covert. I consider every point you make to be a part of the Test Automation effort.