test scenarios and permutations of business processes than a tester can cover through manual testing. For some companies covering more test scenarios with different data values may mean the identification of more defects and bugs before an application under test is released commercially. Some companies may prevent lawsuits, loss of contracts, financial losses and damage to their reputation by building more robust software applications that meet all the intended requirements. These are areas where automated test tools may maximize their ROI. For example the automated testing tools may prevent a company from losing millions of dollars though a lawsuit due to their faulty software product or may help a company generate more revenue by keeping satisfied customers.
The test manager should decide where the test tools would be installed. For instance some projects that I have worked with have dedicated test labs with hardware equipment for the testing team, where the tool administrator can install the automated testing tools. Other projects that I have been involved with do not have a dedicated test lab and the automated testing tools have to be installed on individual testers' desktops. I have also seen examples where the installation of the testing tools whether at a test lab or individual desktop is irrelevant since the automated testing software is web based and can be invoked from a web browser without requiring any installation at the client machines.
Misconceptions of automated testing
Often vendors trump their automated testing products as the panacea for having consistent and repeatable test scripts. In fact a selling point for a software vendor is the perceived notion that test scripts once automated can be re-used over and over and thus saving testing time. Although I would agree that this argument from the vendor has merits, this argument is shortsighted and suffers from the tunnel vision effect. In order to have a repeatable test script that is valid for re-use for various software releases the underlying test conditions under which the test script was recorded, and the underlying application under test's data and environment would have to be static and constant every time the automated test script is executed. This is seldom if ever the case. Most projects have their software undergo some sort of change from release to release, after bugs are discovered, after customer complaints, or after undergoing a gap analysis. Once a test script is recorded and it is underlying conditions on which it was recorded have changed the script needs to be modified and maintained for correct playback on an application that undergoes changes.
We can safely say that test scripts are repeatable when conditions for the application under test stay constant after the script was recorded. And this concept works during a single release when the testers conduct regression testing and in essence re-execute the previously executed test script without making any modifications at all to the script or possibly to the data that the test script is accessing if the test script has been parameterized.
However, for the most part given the nature of ever changing IT applications one may assume that test scripts will require modifications after the underlying conditions in which the test script have changed and are repeatable only to the extent in which the underlying test conditions under which the test script were recorded remain constant or static.
2. Automating a script only involves Record/Playback
As previously mentioned automating a test script is more than merely recording and playing back the test script.
The challenge of automation is to identify skilled personnel with a sufficiently proficient technical