Repeatable Test Cases with Static Data
The true cost benefit of test automation is achieved only when the same scripts are executed multiple times. The first execution is very expensive because it includes the one-time cost of the automation tools and 100% of the Test Automation engineer’s time. When the scripts are executed again, the cost of test automation declines sharply. The tool has already been purchased and the scripts have already been coded. If there have been changes in the application, the scripts may require maintenance before being executed. Maintenance on minor software updates should be minimal.
Because test automation is only successful when the scripts can be executed multiple times, only application which require the same test cases to be executed with the same data are good candidates for automation. For example, a mortgage application that needs to be regression tested on a weekly basis could be a good candidate for test automation. Script maintenance is minimal and the scripts can enter a mortgage application using the same group of test data in a fraction of the time it would take a manual tester to test the same functionality.
On the other hand, a mortgage origination system, which cannot use the same test data for each iteration would not be a good automation candidate. Due to the nature of mortgage systems, data could be staged in various states of approval or rejection, based on the current data and the departments who have already processed their part of the mortgage application. If the script cannot easily figure out what data to enter in the software, it is not a good automation candidate.
Another problem with automating this type of complex system is that the test environment often contains a sampling of production data that is refreshed on a periodic basis. Sometimes this can be overcome by rebuilding the test data when the test environment is refreshed. The feasibility of rebuilding test data on a regular basis depends on the complexity of the application. You will have to make that decision on a case-by-case basis.
Application or Environmental Stability
Environmental stability is crucial to a successfully automating a software testing project. Scripts cannot be coded in a timely manner if the application environment is unavailable, experiences frequent down-times, or excessive defects and errors.
Little or No Application or Environment Downtime
It takes longer to write scripts than it does to manually test the same functionality. Most automation tools are watered down version of C or Visual Basic, which means that writing automated scripts is essentially programming and takes adequate time and specialized skills. Unlike manual test cases, which can sometimes be written based off requirements and mock-ups, automated tools require the actual application. When a test environment is unavailable, automation engineers cannot create scripts, which prolongs the project and ends up costing more.
Excessive downtime can consist of any of the following:
Unstable Environment
Lack of Infrastructure Support
Frequent Application Updates
Buggy Code
Effects of Environment Instability on Script Development and Execution
When an application or environment is unstable, scripting progress is dramatically slowed or stopped altogether. In some cases, it’s possible to continue scripting, but this may causes more work at a later date. For example, if you are scripting in buggy code, you may have to script around error messages and the scripts will have to be revised at a later date. Or, you may only be able to create scripts to a certain point and finish them at a later date. To help avoid and decrease environment instability, read the chapter on Service Level Agreements.