Organize, Automate, Succeed
Stories Columns Opinions Resources
Preflight builds spread wings for smoother projects
Developers are increasingly turning to preflight builds, allowing them to experiment with ...
|
Coverity creates program to enforce code adherence
The Architecture Analyzer uses mapping technology from the company's Software DNA static a...
|
QCon 2008 features domain-driven development
This year's QCon invites speakers like Eric Evans and Dan North to talk about domain-drive...
|
.NET similarities prove golden for Silverlight
Microsoft has focused on making Silverlight 2 symmetric with the .NET platform, and that h...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Advanced Corda CenterView™ Data Visualization for the BusinessObjects™ Intelligence Platform
Corda Technologies presents a white paper on pervasive BI. The BusinessObjects business in...
|
From Mobile to SOA: A Guide for Optimized Application Deployment
Customer need has driven the emergence of multiple computing tiers. Today’s application d...
|
e-Kit: Web Application Security
Is your network secure? What about your web applications.
If IT security is your top p...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
By Edward J. Correia
July 8, 2008 —
A desk sign of a respected co-worker years ago read, “Organize, prioritize, succeed.” That simple three-step plan has stayed with me ever since—its strength is in its simplicity.
The title of an article submitted for Software Test & Performance magazine a few weeks ago brought to mind those three visionary verbs and the variation on “organize, automate, succeed” as the theme of the advice from Vladimir Belorusets, an SQA manager at Xerox. He’s responsible for the quality of the company’s enterprise content management applications and has been a conference speaker on the subject of test automation.
In a future issue of the magazine, Belorusets writes about “Organizing Data in Test Automation Frameworks” and how to use automation architecture to “store, reference, group, share and reuse test scripts and test data.” By organizing things in this way, he says, testers can achieve success in their automation projects by leveraging a test automation framework. “The framework is a common structure where you plug in scripts and data from independent test automation tools,” giving way to easy test data manipulation and maintenance, which he cites as one of the key aspects for framework viability.
He explains how to use the framework to manage both local and global test data. “Related test scripts are usually assembled into logical groups—called test sets—to cover a specific functional area in the application under test.” A test set defines a list of scripts that must be executed by the test automation framework. “One script can belong to multiple test sets and run with different instances of test data. The framework extracts copies of the scripts along with the associated data files from the script repository and runs them on distributed hosts in a sequence defined within the test set.”
Test data can be classified according to scope. “Global test-set data are shared and visible to all scripts within a test set, and local data are visible only within its originating script,” he further explains. Global test data usually represent configuration parameters such as server name, starting Web page URL, etc., that are common to all scripts.
Every test automation framework architect should answer the following questions:
• How do we implement global data?
• How can we change the local data for the script and/or overwrite it for the new test set?
• If later we want to rerun the script with the data from the previous test set, do we need to reenter the data?
• How do we preserve the original test data?
• Do we need to keep multiple instances of the data files for each script?
The success of a test automation framework depends on how effectively it supports test data modification while avoiding the conflicts of overwritten script data within the different test sets. All this, he says, comes down to design rules:
• Test data must be separated from the test scripts.
• Test data should be presented within the tables.
• Data tables should be provided in external files and be easily available for modification to the test case consumers.
• Global data common to each test script within a test set must be separated from the local script data.
• Local test data should be uniquely associated with both the test script and test set that contains the script.
• If a test script is included in multiple test sets and needs to be executed with different test data, the local data for each test set should be separated and coexist within the same data file.
“Based on the industry practices," said Belorusets, "I developed [this] list of general design rules that proved to be efficient for organizing test data within the frameworks. These rules should be considered as functional specifications when developing test automation frameworks in-house or evaluating commercial frameworks.”
Belorusets’ complete test automation plan will be featured in a future issue of Software Test & Performance. Don’t miss it!
Share this link: http://www.sdtimes.com/link/32498