Making The Decision To Automate Your Software Testing Get the Trellian Seo Toolkit
Get our FREE SEO Guide
Subscribe to our newsletter to receive useful SEO tips, tricks, strategies, free ebooks that are available only to our subscribers and get this amazing SEO guide for free!

Your email is safe and will NEVER be shared with any other parties. And of course, you can unsubscribe at any time.

Name:
Email:
SEO Elite - #1 SEO Software

Who Else Wants To Finally Get A #1 Google Ranking In As Little As 7 Days... And Drive A Minimum Of 789 Unique Visitors To Your Websites Per Day?

Fake Pagerank Checker PHP Script

This script checks if the google pagerank of a website is real or is faked by using the 301 or 302 redirects.

Only $9.95
Coming soon ...


Self SEO Store  
SEO forum
Website templates
Flash templates
Best hosting reviews.
Free Internet & IT Magazines.
Articles archive

Submit your article

Register
Login

Search
XML news feeds
Free RSS news reader
Contact


AddThis Feed Button

Making The Decision To Automate Your Software Testing

Posted by Danna Henderson on: 2005-04-07 01:58:51

Self SEO > Hardware Articles


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 2005. Danna Henderson. All Rights Reserved.

About the Author

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 Consultants.





Print this article    Tell a friend
Post New Comment

This site does not allow anonymous comments. Registered members can login to participate. Registration is free and takes only a few seconds