Data driven scripts are those application-specific scripts captured or manually coded in the automation tool’s proprietary language and then modified to accommodate variable data. Variables will be used for allowing the script to drive the application with external data supplied by the calling routine or the shell that invoked the test script. This data are basically known as 'Test Data'

 

Hard Coded Component Identification

Consider the below example of activating a server-side image map link in a web application with an automation tool scripting language:


selenium.Click("ctl00_cpmid_LeadAllocationListUserControl_LeadAllocationListRepeater_ctl01_MoreInfoImageButton");

 

 

This particular scenario of clicking on the image map might exist thousands of times throughout all the scripts that test this application. The preceding example identifies the image by the title given to the document and the index of the image on the page. The hard coded image identification might work successfully all the way through the production release of that version of the application. Consequently, testers responsible for the automated test scripts may gain a false sense of security and satisfaction with these results.

However, the next release cycle may find some or all of these scripts broken because either the title of the document or the index of the image has changed. Sometimes, with the right tools, this might not be too hard to fix. Sometimes, no matter what tools, it will be frustratingly difficult.



Highly Technical or Duplicate Test Designs

 
Another common feature of data driven scripts is that virtually all of the test design effort for the application is developed in the scripting language of the automation tool.

Either that, or it is duplicated in both manual and automated script versions. This means that everyone involved with automated test development or automated test execution for the application must likely become proficient in the environment and programming language of the automation tool.

Findings:

 
A test automation framework relying on data driven scripts is definitely the easiest and quickest to implement if you have and keep the technical staff to maintain it. But it is the hardest of the data driven approaches to maintain and perpetuate and very often leads to long-term failure.



Views: 12

Comment

You need to be a member of Test Republic to add comments!

Join Test Republic

© 2014   Created by Test Republic.

Badges  |  Report an Issue  |  Terms of Service