One of the major barriers to test automation is the volatility of the application to be tested. Even benign changes such as moving a button to a different part of the screen or changing a label from 'Next' to 'Continue' can cause test scripts to fail. This problem is especially acute when testing an application's functionally at the GUI level because this tends to be the area in which changes are most frequent. For this reason, test teams have historically tended to avoid functional test automation until an application has become stable. However, this approach does not work when building SaaS products or developing products in an Agile environment where change is a constant. In this situation, a more sophisticated test approach is required to avoid incurring 'technical debt' (i.e., quality issues or tasks that are deferred to be addressed later or not at all).

Develop a Reusable Subroutine Library

The first level of sophistication in test automation is to develop a library of reusable subroutines that will encapsulate and hide an application's implementation details from the test scripts themselves. For example, you might implement a test subroutine called 'login_to_my_app()' that accepts two parameters: 'UserName' and 'Password'. At runtime, this test subroutine will first find the appropriate text fields in the application GUI and then execute the keystrokes and mouse movements required to fill in the given user name and password, thus completing the login operation. If the application's login GUI changes (e.g., if the on-screen label for 'User Name' is changed to 'Login Name'), then the 'login_to_my_app()' test function might also need to be updated. However, the scripts that called this subroutine would not need to change.

The reason this type of abstraction is a win for some projects is that, in this scenario, a change to the application now only requires you to maintain a single subroutine rather than potentially hundreds or thousands of test scripts. Since complex applications frequently have thousands of test scripts, the savings in effort and time is clear. The trade-off is that the level of skill required to maintain a subroutine library is generally higher and of a different type than that needed to maintain test scripts. Obviously this requirement will change your staffing profile and cost structure.

However, the benefit of this approach is that you can accommodate change much more readily. More importantly, it will allow you to safely write test cases before the application has been fully implemented. Test script writers only need to know (a) the software's functionality and requirements and (b) the 'stubs' of the test subroutines that will be implemented. You can significantly compress your implementation schedule by enabling your development and test automation processes to function in parallel.