By Eduardo Amaral, Quality Management Director at Noesis
Test automation is one of the top priorities for organizations today. All, or almost all, are betting on it, intending to reuse the effort of performing manual tests, avoiding the turnover of people in projects, motivating employees, and saving time in marketing products and services.
But before jumping into the automation theme, some aspects must be considered to achieve the goal we seek.
The first thing to do is to analyze that three crucial areas need to be included in any test automation process: tools, test environment, and coverage, although it is not necessary to do it in this order because all the steps are related.
Tools
In the area of tools, the first step is to consider which tool meets our needs. It is essential to assess our needs and look at the types of validation, architecture, and solutions that allow us to build, manage, and report on the automation project.
The process of selecting an automation tool for web or mobile is not the same that we should consider if we think of an SAP system, for example. So, in that case, we have to take a more specific approach to technical support and tools that fit the type of system chosen.
Test Environments
In the field of test environments, we need software, licenses, infrastructure, and a log of runs and parameterization. So it is necessary to define the test data management strategy and the requirements for Continuous Testing. In many cases, it is vital to keep in mind that we need a lot of data to get sandboxes up and running. This is an aspect that cannot be ignored.
Coverage
In terms of coverage, what we have to evaluate is what we want to automate. The initial assessment should aim to define which business processes we will automate. To do this, we must identify the type of applications we have, the repetitive tasks, and what we want to automate. Likewise, we must define at what level we will implement test automation.
Having these three fundamentals well established, we can look at some additional steps, such as the identification of the pilot application, the identification of small validation steps, which should be performed step by step to manage expectations appropriately, and the automation criteria, which are used to identify the stability of the application in a test phase. In this regard, we have to be sure of what will be used and assess the life cycles of the application; whether it will be used for a long time, whether it is obsolete, or whether the testing time is acceptable.
Last but not least, we should look at the ROI (Return On Investment).
Considering both the automation costs and the other associated costs, the important thing is to estimate the balance point for the development effort, support/maintenance, and the tasks that must be performed manually. We will find the balance when we reach approximately 80% profit (considering the use of automation) and 20% effort (of what would be the total amount to automate 100% of the coverage).
In this sense, each organization must define the levels of automation it will implement and its level of scaling. For example, a first level can be determined which corresponds to a basic level; a subsequent, more productive level, where a roadmap, defined objectives, and KPIs already exist; a level above where a more consolidated automation framework is described, working on processes and not only on applications; finally, a more advanced level, where advanced themes such as artificial intelligence are introduced.
These levels are a priority reference for organizations to define their strategy. The ideal is to have a detailed scale of priorities. So as you increase the coverage by 60-80%, the investment starts to decrease. This is a key aspect to consider before starting your automation journey.
Ultimately, it is important to focus on the future uses of test automation, based on best practices in the market, as well as how to get the ROI you want to achieve and good ways to measure it.
Published (in Portuguese) in Computer World
