Changes to an existing TAS require careful planning and investigation. A great deal of effort has gone into creating a robust TAS consisting of a TAF and component libraries. Any change, no matter how trivial, can have far-reaching effects on the reliability and performance of the TAS.
Identify changes to the components of the test environment
Assess what changes and improvements need to be made. Do these require changes to the test software, custom function libraries, or the operating system? Each of these will have an impact on the performance of the TAS. The overall goal is to ensure that automated testing continues to run efficiently. Changes should be made incrementally so that the impact on the TAS can be measured by a limited number of test scripts. Once it is determined that there is no adverse impact, the changes can be fully implemented. A full regression run is the final step to validate that the change has no adverse impact on the automated scripts. Errors may be found during the execution of these regression scripts. Identifying the cause of the error (through reports, logs, data analysis, etc.) ensures that the errors are not due to the automation improvement.
Increasing the efficiency and effectiveness of core TAS function libraries
As a TAS matures, new ways to perform tasks more efficiently are discovered. These new techniques (e.g., optimizing code into functions, using newer operating system libraries, etc.) must be incorporated into the core function libraries used by the current project and all projects.
Consolidation of multiple functions acting on the same control type
A large part of an automated test run consists of querying controls in the graphical user interface. This query is used to obtain information about that control (e.g., visible/not visible, enabled/not enabled, size and dimensions, dates, etc.). With this information, an automated test can select an item from a drop-down list, enter data into a field, read a value from a field, etc. There are several functions that can act on controls to obtain this information. Some functions are very specialized, while others are more general in nature. For example, there may be a special function that only works on dropdown lists.
However, there may also be a function (or a function may be created and used within the TAS) that works with multiple functions by specifying a function as one of its parameters. Therefore, a TAE may use multiple functions that can be consolidated into fewer functions to achieve the same results and minimize maintenance.
Refactoring the TAA to accommodate changes in the SUT
During the life of a TAS, changes must be made to accommodate changes in the SUT. As the SUT evolves and matures, the underlying TAA must also evolve to ensure that the capability is there to support the SUT. As features are added, care must be taken to ensure that they are not implemented as an afterthought, but are analyzed and modified at the architecture level of the automated solution.
This ensures that if new SUT functionality requires additional scripts, compatible components are in place to support these new automated tests.
Naming conventions and standardization
When changes are introduced, the naming conventions for new automation code and function libraries must conform to previously defined standards (see Article Test Automation Maintenance).
Evaluate existing scripts for revision/elimination of SUT
The change and improvement process also includes an evaluation of existing scripts, their use, and their continued value. For example, if certain tests are complex and time-consuming, it may make more sense and be more efficient to break them into multiple smaller tests. By selectively eliminating tests that are rarely or never run, the complexity of the TAS is reduced and it becomes clearer what needs to be retained.
Source: ISTQB®: CTAL Test Automation Engineer Syllabus Version 1.0