Caution! Avoid Low-Value Automation Practices

Published on
October 25, 2022
Steve Moss
Principal Consultant

When switching to a new testing tool, there can be a lot of adjustments to finding best practices.

One of the main reasons for organizations to focus on their investment in automated testing approaches is to transition away from an over-the-fence testing culture and move towards a continuous testing approach. In manually heavy teams, a great focus is placed on functional testing for example on a graphical interface or web application, and less focus is placed on other testing types due to time constraints on projects and deliveries. These time constraints stem from the manual testing being expensive to the testing activities, especially when the majority of all sign-off activity consists of manual, repetitive regression test activity, or testing that the latest changes have not had an inadvertent knock-on impact on existing functionality.

The benefits of automated testing include the ability to run your tests quickly, repeatedly, and with consistency, therefore, logically we can assume that the incorporation of test automation into your testing activity will free up team members to focus on other higher-valued test activities, reduce team sizes, reduce costs, and deliver faster results.

While it is certainly true that you can execute your automated tests on demand and gather results faster and more accurately, there is a bit of a misconception about what that means in terms of your delivery practices, the costs, and how the team dynamic changes. 

Adopting a test automation approach often takes a flow similar to the following:

  1. Review the available automation tooling capabilities against current/future requirements
  2. Proof of concept
  3. Tool Selection
  4. Training and Support
  5. Recruitment

For starters, there are a multitude of test automation approaches that can be taken to achieve an organization’s test automation goals, for example, these approaches include, but are not limited to:

  • Click, Record, and Playback
  • Coded Frameworks
  • Modular Frameworks
  • Robotic Process Automation

The automation approaches can be quite different from each other, and the features on offer can also be quite different - one approach may also lend itself better in a given domain than another, but this is not always readily apparent and takes time to familiarize with the solutions to learn about the benefits and the limitations. 

Paired with the features on offer, tool selection needs to consider that each approach also offers different capabilities when considering criteria such as authoring, execution, reusability, reporting, and maintainability.

So, let’s assume you have selected your tool, and you are about to embark upon your test automation journey. Now you need to get going and demonstrate the value and get rid of all of that repeatable activity in your testing… well, what if I told you that if you don’t plan appropriately, you run the risk of trading off one set of repeatable activity with another?

Let’s assume you have decided to embark upon a coded automation solution, such as using Selenium. You now have a load of challenges to consider like how to structure the tests and maintain the framework approaches, or the addition of extra packages to achieve some capability missing in the default Selenium space. As you proceed on your automation journey, you may have planned to automate as much as possible in every development iteration, and in a short order of time, you may find that you are in fact spending as much time (if not more) maintaining the framework as you are authoring new tests. You may be finding that initial framework design decisions don’t scale with your current requirements, and not to mention every single person who has been contributing to the code may have been altering it ever so slightly until you need longer and longer to understand how to achieve an outcome with the framework. While you went on this journey, you realized that you needed to upskill people around coding practices in your selected development language or you had to recruit specialists. 

The point of the above is to explain that if you are not aware of the above, you can end up in a similar situation to where you started: spending a lot of time and effort not actually testing but writing code to help solve the next challenge. This set of challenges also makes the adoption of automated practices more difficult for organizations and makes it even harder for some organizations to build confidence in their adoption of a new test automation tool.

The importance here is tool selection and trying to limit the amount of time spent worrying about your framework and placing more focus on authoring your tests. Tools that enable this focus has an advantage in reducing this issue; tools like Virtuoso. Keep your processes efficient and time-saving by authoring with Natural Language Programming and letting tests maintain themselves. See it all for yourself with our two-week trial.


No items found.

Subscribe to our Newsletter