Introduction of Automated Test to a Project

lost while learning to work with the test tool or ramping up on tool features and capabilities has put the test effort behind schedule. In such situations, the team may become frustrated with the use of the tool and even abandon it so as to achieve short-term gains in test progress. The test team may be able to make up some time and meet an initial test execution date, but these gains are soon forfeited during regression testing and subsequent performance of test.

In the preceding scenarios, the test team may have had the best intentions in mind, but unfortunately was simply unprepared to exercise the best course of action. The test engineer did not have the requisite experience with the tool or had not defined a way of successfully introducing the test tool. What happens in these cases? The test tool itself usually absorbs most of the blame for the schedule slip or the poor test performance. In fact, the real underlying cause for the test failure pertained to the absence of a defined test process, or where one was defined, failure to adhere to that process.

The fallout from a bad experience with a test tool on a project can have a ripple effect throughout an organization. The experience may tarnish the reputation of the test group.

Confidence in the tool by product and project managers may have been shaken to the point where the test team may have difficulty obtaining approval for use of a test tool on future efforts. Likewise, when budget pressures materialize, planned expenditures for test tool licenses and related tool support may be scratched.

By developing and following a strategy for rolling out an automated test tool, the test team can avoid having to make major unplanned adjustments throughout the test process. Such adjustments often prove nerve-wracking for the entire test team. Likewise, projects that require test engineers to perform hundreds of mundane tests manually may experience significant turnover of test personnel.

introduction process. This process is essential to the long-term success of an automated test program. Test teams need to view the introduction of an automated test tool into a new project as a process, not an event. The test tool needs to complement the process and not the reverse.

Test Process Analysis
The test team initiates the test tool introduction process by analyzing the organization's current test process. Generally, some method of performing test is in place, and therefore the exercise of process definition itself may actually result in process improvement. In any case, process improvement begins with process definition.

The test process must be documented in such a way that it can be communicated to others. If the test process is not documented then it cannot be communicated or executed in a repeatable fashion. If it cannot be communicated or is not documented then a process is often not implemented.

In addition, if the process is not documented then it cannot be consciously and uniformly improved. On the other hand, if a process is documented it can be measured and therefore be improved.

If the organization’s overall test process is not yet documented, or it is documented but outdated or inadequate, the test team may wish to adopt an existing test process or adopt an existing test process in part. The test team may wish to adopt the Automated Test Life-cycle Methodology (ATLM), outlined in the book "Automated Software Testing," as the organization's test process.

When defining or tailoring a test process, it may prove useful for the test engineer to review the organization’s product-development or software-development process document, when