the group, team members who immediately grasped the concept and the techniques for creating methods, the creation of variables, the idea of passing arguments to a variable, having central files that identified the application objects, and these resources were quite comfortable doing so.
These few resources were adopted by the test group as an ad hoc source of expertise. As time permitted they helped team members with problems, offered suggestions as to methods, and were generally keeping the automation effort afloat. They were loosely called an automation team but had no specific responsibilities or goals; they were basically a “finger in the dike.”
During this time, products were expanding, new products were added, and many products experienced significant functionality and user interface changes. An inventory of manual test cases during the late summer of 2000 indicated there were approximately 9,500-10,000 manual test cases as opposed to several hundred automated scripts that had an extremely short useful life.
Decisions were made concerning the automation team and the automation process.
What Was Done
The automation team was assigned a team lead whose directive was to deal with the deficiencies in the automation process. The team would take on all automation and free the test staff to create documentation and perform their tests without the onerous, to the test staff; burden of creating usable automated test cases. There was also the extremely large number of manual tests cases, priorities to be assigned and implemented and a method to accomplish all this.
A Flagship product with a large number of tests cases was selected to begin the effort. A contractor was asked to supply a Project Manager and ten skilled developers who however had no skills with the automation tool’s language. The automation team members provided an automation tool user’s guide and hands on training and in approximately four weeks the team was able to develop approximately 500 automated test cases. This effort alone reduced the execution time for these tests from 40 person hours to ten hours of running time. It became clear that automation, properly done, is effective. There was still a large body of manual test cases waiting for automation.
During this effort the team was building the outline of a formal automation process. It was imperative to the success of the team and the automation effort that a clearly defined path exist for the test staff to present a request for automation, to be advised where test plans did not lend themselves to automation, to be provided feedback and suggestions where changes could be made that would then permit the test case to be automated. The requester would be provided with a sizing, that is to say how long it would take to complete the automation. A priority was assigned so that the requester knew exactly where they were in the queue and when they could expect to have access to the automated product.
The first part of this task was the creation of the Automation Process document. This document describes in its entirety the process, the flow of the work, the responsibilities assigned to the automation team members and those of the testing staff. What the deliverables are for each of these groups. Who would do maintenance when it was required, and, if maintenance was assigned to the test staff, it outlined the provisions for staff training so that the staff could complete tasks of this nature.
The team recognized that standards would be essential to the success of the automation effort. Using software development best practices, a standards document was created and reviewed and then implemented. All code