Automating in Agile Environment

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 applications 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 applications 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 applications 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 softwares 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.

Conclusion

Without a doubt, developing a library of reusable subroutines to test your system requires an up-front investment. 

However, in situations where you:
1. Need to build or customize a SaaS product
2. Wish to truly gain the benefits of an Agile, test-driven development methodology
3. Need to compress your test and development schedule as much as possible while still ensuring high quality; or
4. Must cope with constant change during pre or post-deployment, taking a more sophisticated approach to test automation can be a lifesaver for your project.

via Making Automated Functional Testing Work in SaaS and Agile Environments

Posted in: Agile, Automation, Custom Web