Making Decision Automate Software Testing

Not every software testing project can or should be automated. Before your department accepts a new test automation project, you should establish a process by which projects are reviewed and either accepted or rejected. This can be done with a simple Test Automation Acceptance Checklist.

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.

Timely Defect Fixes

Application defects do not have to be detrimental to an automated software testing project. When defects are fixed in a timely manner, scripting can continue without significant downtime. When estimating an automated testing project, it's always best to add some buffer time that will accommodate for defect reporting and revisions.

When defect fixes take an excessive amount of time to resolve and are causing the automated software testing project to be delayed, it's time to pull together a meeting. Invite all the major players and discuss the root of the problem and what everyone can to improve the situation. Maybe development is spending too much time trying to reproduce the problem and having your automation team enter better description would help them turn the defect fixes around faster. Maybe you can work together to classify defects and establish reasonable fix times for each classification. For example, a Critical defect needs to be fixed that day while a High defect needs to be fixed with in 24 hours.

Responsive Contact Person

When your team takes on a new automated testing project, you will need a contact person. This person is responsible for making sure you have the business requirements and answering questions about how the application works. This will not be his or her main job, so you will need to make sure he or she is responsive. If you cannot get adequate business requirements, test data, or questions answered, your automation project will not be successful.

Copyright 2004. Danna Henderson. All Rights Reserved.

Danna Henderson has helped many organizations automate their software testing with WinRunner. For information on creating robust, data driven scripts, and successful automated testing, visit WinRunner Experts.

XML error: not well-formed (invalid token) at line 14

Common misspellings for words used in this page include accomadate accomdate accomodate acheived achived actualy adavanced addres addtion adecuate adminstrator adn adres adress affort ahev ahve allready almsot alomst alreayd alsot alwasy alwyas amke amking ammount anbd anohter aplication applicaiton archetecture architechture aready aroud arround artical artice articel arund aslo availaible availble availiable availible avalable avaliable avilable baceause bakc baout basicaly basicly bcak beacuse becasue beccause becouse becuase bedore befoer beggin beleive beleived belive belived beng benifit betwen bewteen buisness busineses busness bussiness candadate candiate candidiate cannnot cant carefull catagory ceratin certian claer clera cmoputer comany comapany comback comming compability compatability compatablity compatiblity competance concider consdider containes coputer coudl countains creaeted criterias currenly decison decribe decribed decribes delevopment descibed descision descriibes descripton descuss desgined dessigned detremental developement develpment devolopement diferent diferrent differnt diffrent discribe discribed discribes doens eahc eiter ened engieneers enviorment enviornment enviroment enxt equialent equivelant equivelent equivilant equivilent equivlalent especialy essentialy ethose eveyr excecuted excecution exection exectued expecially fiel finacial follwoing folowing fomr frome ganes gogin goign gonig gropu haev halp helpped howver hten htere htey htis hvae hvaing hvea hwihc hwile hwole importamt inbetween inclreased indepedence independance independece indipendence infomation informtion inital inot instade instatance intergrated intergration intial intrest iwll iwth knwo konw kwno laguage levle liek littel liuke loev lveo lvoe maintainance maintainence maintance maintenence majoroty managment marjority marketting mkae mkaing mkea moreso morgage mroe neccesary neccessary necesary nessecary nkow nkwo nowe nto oftenly oging omre onyl otehr owrk owudl palce pary peice peronal possable possibile prefered previvous probablly probaly probelm proccess proccessing procedger proceedure proces propper raelly realy realyl rebiulding recquired recrod regluar rela relaly relatiopnship relpacement reponsible requred responisble responsibile rocord rwite scirpt seach seperate severeal sevice shoudl shoudln siginificant signficant signficiant signifigant similiar simmilar simpley smae smoe soem sofware sohw somtimes sould specfic specif stablility stlye strat stregth strenght stucture sturcture succesful succesfully succesfuly successfull successully succsessfull sucesful sucesfully sucesfuly sucessful sucessfull sucessfully sucessfuly sytem sytle tahn taht tath technnology technolgy teh tehy tghe thast ther theri thgat thge thier thikning thn thna thne thsi thsoe thta thyat tiem tihs timne tiome tje tjhe tkae tkaes toghether traditionnal tyhat tyhe typcial typicaly uise unsed untill usefull useing verison vetween veyr vrey vyer vyre waht wass watn weas wehn whant whcih whic whihc whith whlch whn whta wich wiew wih wiht wille wirting witht witn wiull wnat wohle wokr worls woudl wriet writen wrok ws wtih wupport ytou yuo.