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