Working With Automated Testing Tools

A Pragmatic Approach
Member Submitted

faith in the testing tool and resist using it. I have seen this happen in particularly with test management tools that serve as the repository for test cases, and test sets, and defect reporting test tools and have large population of end users. The tool administrator should be able to answer and respond to the questions that the end users present when they have problems using the test tools.

Automated tool’s process owner
In addition to appointing the automated testing tool administrator the test manager should also appoint the testers or group that own the processes for using and working with the automated testing tools. The automated software tool's process owners develop the specifications as to how they want to see the testing software customized. A paradigm of a process that could be customized is the workflow process for reporting defects and the fields that need to be populated for creating a defect based on a company's defect reporting procedures. Another example of a process that could be customized are the fields that need to be populated or created from scratch, within a test management tool in order to create a test case.

Another task assigned to the automated tool's process owners is the creation of customized internal training materials for the end users of the automated testing tools within the project.

The roles of the tool administrator and the tool process owner should be complementary. For example the process owner may specify how the particular test management tool will be customized and in turn the tool administrator would perform the associated tasks to customize the test management tool.

Who will perform the automation
Developing and creating automated test scripts requires programming skills. Many organizations erroneously assume that any tester within the testing team, or QA team has the ability to write code for test scripts because they believe that creating script is a simple matter of just "record/and play back". This is a fallacy and it behooves test managers to avoid this fallacy.

Writing and developing scripts with an automated testing tool requires knowledge of the test script language, the ability to embed exception handling logic within the script, insertion of logic operators, while loops, for loops , parameterization of test scripts, correlation of test scripts, adding verification points to the script, adding logic to recognize objects within an application, etc. Merely recording a script does not assure that a script will playback successfully specially when the script is data-driven. After the test script is recorded the automation test engineer needs to "massage" the script and tailor the script until it successfully playbacks back in a manner consistent in which an end user would execute the transactional steps of a test script.

Just in the same way that writing code and developing code to produce an application requires technical skills so too is developing automated test scripts. The test manager should recognize which members from his/her team will be the core automators with the automated testing tools for the test scripts that need automation and which testers will be responsible for the creation and documentation of the test design and test scripts that will be automated. In some instances a test manager will need to create a test team structure in which some of the testers are divided into subject matter experts with functional and in-depth knowledge of the application under test and core test automators that have knowledge of the automated testing tool but limited functional knowledge of the application under test.

The reader should note that for some applications specially ERP applications the functional testers have much

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.