Choosing a TargetBy Kevin Bingham | Posted 2008-04-30 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
Arizona Federal Credit Union uses test automation to deliver better applications without sacrificing cost, time or quality.
Choosing a Target
This was our first serious automation effort, so rather than scattering our efforts, we needed to focus on a single, achievable target that we could automate in a reasonable timeframe and that would demonstrate tangible results highlighting the value of automation.
We picked an application that was both mission-critical and clearly beneficial to the business. Our business partners had to manually test the application in question, which meant redirecting efforts away from their core goals of providing service to our members. We focused on an application that would enable us to automate about 80 percent of the test cases. As a result, we achieved an immediate buy-in.
When analyzing the test scenarios, we decided the most practical way to get value from our investment was to focus on items with the most impact—namely, test scenarios in which business partners spent the most time defining and executing manual tests. We also engaged our business partners in the early stages of the project, asking them what processes were the most critical to daily operations, which posed the greatest risk if they were deployed with defects and what aspects of the tests were constantly reused—such as logging on, adding a new customer, etc.
It’s not enough to simply focus on the most frequent scenarios, or on the ones that consume the most time. It’s also important to make sure that whatever is being created is highly reusable, in order to minimize the maintenance needed as future application updates roll out. Only after thoroughly assessing our business processes and test automation scenarios were we ready to move to the final implementation step: ensuring that we built test assets that were as maintainable as possible.
We had our testing expert work with business users to guide them in the process of capturing the automated test cases. This ensured that the right steps were being captured to properly automate business processes. Then we took the added step of “componentizing” our approach to anticipate change.
Our framework-based approach enabled us to have a central point of update. By making changes in one place, we were able to reduce maintenance efforts. This approach also gave us the flexibility to modify test assets quickly and easily.
In one situation, for example, the login function changed. Rather than having to update numerous tests, all of which had their own login routine, we were able to simply update the login functionality in our framework. The changes then rolled down to update all test scenarios that made use of this routine. It seems obvious in retrospect, but many automation efforts miss this important step and the vital benefits it provides.