Like many QA engineers, my first introduction to test automation was based upon a tool purchased by my employer before I was hired. This tool had been sitting on the shelf, waiting for the day an unassuming QA engineer could figure out how to get some use out of it.

Soon, I was facing my first project to leverage this tool; honestly, I had no idea where to begin. I clicked and recorded my way through a test case or two and tweaked the auto-generated code, resulting in my first, pieced together automation framework. Like a Rube Goldberg contraption, my automation trudged its way through test after test, helping with the need at hand but never resulting in a long-term solution for our team.

Years later, with a new company, I was given that rare opportunity for a "do-over" and the revelation of how important it was to learn how something was intended to be used.

My employer had arranged for me to have training from the automation tool vendor, Hewlett-Packard. Over a week-long course, we created automation to test a sample application. We drove the test with data from a spreadsheet and interacted with application objects in a variety of ways. When I completed the course, I realized the chasm of difference in how I had first used this tool in comparison to how the tool was intended to be used.

The following are tips I've learned to help make smarter steps into the world of automation. Following these will help you avoid some common pitfalls and help you get greater return on investment from your efforts. 

Selecting a Tool 
Choose a tool that's adaptable to a variety of environments. It should be web friendly as well as capable of interacting with typical windows objects, such as buttons, form fields, and gathering text. It should be capable of working with technologies like mobile and service-oriented architecture. It's reasonable you'll conclude the need for other tools to bridge gaps a single tool might not be able to meet. Try to keep these to what is absolutely necessary with minimal overlap, if possible.

Use as Intended
Ensure you get the proper training, preferably from the vendor that created the tool. You'll want to leverage the tool as it was intended to be used and not in an ad-hoc, discovered approach. This will help you get the most out of the tool and allow you to hire future talent that have also gone through the appropriate training, which is something you can look for during the hiring process. It's an unfortunate reality that much of the automation being developed these days is being done with little to no consideration for how the tool was intended to be used. This often leads to automation efforts that are not maintainable and sustainable in the long run. 

Beware of the Sales Pitch 
With over a decade of experience behind me, I have yet to see a "click-and-record" approach to automation that was usable for any length of time. My point: If the tool demo seems  too good to be true, it probably is. Developing automation that stands the test of time requires planning and effort like any software-development endeavor. 

Identify Good Automation Opportunities 
Contrary to popular belief, regression test cases do not always make the best automation candidates, especially for your first efforts. Consider tasks your manual testers repeat over and over; processes that cover three of four steps but need to be repeated hundreds of times. These are great opportunities and help the manual test team start to identify other repetitive tasks, such as environment configuration or a setup that could be automated. Start simple and progress to more complex automation development. 

Build a Toolbox 
Develop a core library of functions that are application agnostic. I include functions that convert data, compare values, help with logging, etc. Spend time to develop these functions well as they can be utilized across numerous projects in the future. Build a separate library of functions that are application specific. Always include versioning information along with a list of included functions within each of these libraries. 

Object Recognition Expertise 
Become familiar with the various ways your tool interacts with application objects. All objects (windows, buttons, fields, etc.) have properties that distinguish them from other similar objects. Much of the "art" of being an automation engineer is the ability to reliably interact with various types of objects in a sea of similar objects. Avoid using methods where control keys, tabs, and arrows keys are used to navigate to objects; these will prove to be unreliable in the long run. 

Adoption is Important 
No matter how brilliant the automation effort, if no one uses it, precious time and effort have been wasted. You should build automation that serves the testing team. Start with efforts that can be completed within a week or two and monitor if this automation is getting used. Avoid extensive efforts spanning months that may lead to no adoption at all, which is a common reality of many ambitious automation efforts. Start small and move into more complex efforts while paying attention to adoption along the way. 

The N-Curve Effect 
The principal of the "N-Curve Effect" is that all automation requires some level of ramp-up effort, in which foundational components are put into place before the first test case can execute end to end. It can be hard to see the value of automation during the initial, steepest part of this curve, much like it can be difficult to envision a house while the foundation is being put into place. Be realistic as to how long it will take to lay the automation foundation. Once this foundation is in place, build additional automation that leverages this foundation to get the most out of the initial efforts.

I hope you've found these tips helpful as you embark upon your automation journey. A smart plan for your automation endeavors will make a significant difference in its usefulness, adoption, and maintainability over the long haul.

Let the journey begin.