When I first began my career as a software tester more than two decades ago, I worked on a project that was a great candidate for automation. Consequently, my mentor trained me to use automation as part of my testing protocol from the very beginning. I not only learned what type of applications and projects make good candidates for automation, but I also learned the most effective ways to implement it.

Fast forward five years, and I transitioned to a different company in a software testing role. I moved from testing software designed for an educational institution to testing software in the financial services sector. There was no tradition of automated testing at my new company, and the projects that I took on initially were not good candidates for automation. So, I honed my skills as a manual software tester writing and executing test plans.

Benefits of automated testing

Then, fifteen years ago, my supervisor decided that I was the right member of her team to handle testing for any projects involving what was at the time called “home banking.” The first few projects prompted me to begin looking for a tool that I could use to automate regression testing. I found a very popular, open-source tool that required no license fees and used a language simple enough to allow a user-oriented tester to understand what the various commands did. As I was still the only tester involved, storing the script files as .html documents on our network worked fine for me.

At that time my simple implementation provided me with a few key benefits:

1. Because the language was simple, it offered me a wide variety of options when I needed to add members to my test team.
2. The thought process of structuring the tests and automation process assisted me in creating very thorough test cases that found defects I might have missed otherwise.
3. The speed of playback allowed me to regularly perform more test cases during regressions than I would have been able to manually.
4. The tests provided helpful documentation for the extent of the application’s functionality that I could use in testing corresponding help documentation and marketing materials.

That system served us well for a decade or so until the creator and maintainer of the automation software no longer had the time to support and maintain it. At that point, I began analyzing our current testing needs from scratch. Does automation still make sense? If it does, what are our requirements for an automation tool? What tools are available today that might fit our requirements? What are the costs for the various tools?

I assembled my testing team, and we decided that automation still made sense based on our software and testing environment. We began researching available tools and scheduling demos and test periods. We ultimately chose a tool with an integration to Git so that we could manage our code base more easily with multiple testers working on the same projects. It also has an object repository so that when the identifier of a control changes, I only need to update my code in one place to reconnect my tests to that object.

Now, our implementation of automated testing provides all of the former benefits and some additional ones:

1. Our tool offers the ability to test at multiple layers of an application. I can write scripts to test at the API layer of the application, and I can then write scripts to test the UI layer of the application.
2. Our tool allows us to perform automated testing on mobile apps, and not just browser-based applications.
3. Our new system allows us to easily do code reviews to check for the completeness and efficiency of our tests.

Test it for yourself!

As you can see, when the type and scope of the software you are testing call for it, automation can be a huge asset to your attempts to achieve quality assurance. Over the years, not only has the technology of our applications under test changed—the technology of the automation tools has matured as well, increasing their value to the discerning tester.