Carl Nagle's DDE Framework

Nagle's approach moves test automation to the third level as it uses a nontechnical front end (a table-driven approach that is implemented in MS Excel format) that describes the tests to be performed, lays out the test scenarios, and implements the steps to be executed. When the tables are parsed by the DDE, the DDE executes automated tests without the user needing to write test script code.

DDE Overview

Carl Nagle of SAS Institute developed this framework for SAS (SAS Institute owns the intellectual property rights to the DDE), but also released it to the public domain as is indicated in the following copyright information:

Copyright (2001) SAS Institute Inc. All rights reserved.

NOTICE: Permission to use, copy, modify and distribute this code and its documentation, if any, for any purpose and without fee is hereby granted, subject to the following conditions:

Note: This copyright permission notice must appear in all copies of the code and in any related documentation.

The DDE concept is another alternative to the capture/playback approach. The main reason for test automation implementation failures is the maintenance burden associated with the capture/playback method. Automated test script development is application development, and a set of automated test scripts constitutes a software system to test another software system. As the application software tested by the scripts evolves, the scripts themselves require maintenance to keep them working.

The level of the maintenance effort depends on the implementation approach. Capture/playback test scripts require the most maintenance because they contain both test procedure commands and test data; everything is hard coded in the test script. The keys to maintenance reduction are to remove the test data from the script and use that data to drive the test script, as well as to develop reusable subroutines and functions that can be shared across automated testing projects.

The Archer Group approach (discussed in the previous section) does this using CSV files containing two types of data: The first data type functions to direct the test script's navigation in the AUT and to direct the actions it performs against the AUT. The second data type is the actual test data used by the script to implement specific tests of the AUT. The script control data and the test data are developed in Excel spreadsheets and exported to CSV files in the format Rational Robot requires.

The DDE method is very similar, but it has been enhanced so that nontechnical testers can also develop test data. Test data development involves construction of a hierarchical set of tables in MS Excel that drives the tests of the application. These tables include three types of driver tables—Cycle Driver tables, Suite Driver tables, and Step Driver tables. The Cycle Driver table is the highest level and the farthest removed from the actual test. Figure 7.1 illustrates the DDE automation framework structure.

The DDE method is best described in Nagle's own words:

…the framework itself is really defined by the Core Data Driven Engine, the Component Functions, and the Support Libraries. While the Support Libraries provide generic routines useful even outside the context of a keyword driven framework, the core engine and Component Functions are highly dependent on the existence of all three elements.

The test execution starts with the LAUNCH TEST script. This script invokes the Core Data Driven Engine by providing one or more High-Level Test Tables to CycleDriver. CycleDriver processes these test tables invoking the SuiteDriver for each Intermediate-Level Test Table it encounters. SuiteDriver processes these intermediate-level tables invoking StepDriver for each Low-Level Test Table it encounters. As StepDriver processes these low-level tables it attempts to keep the application in synch with the test. When StepDriver encounters a low-level command for a specific component, it determines what Type of component is involved and invokes the corresponding Component Function module to handle the task.(3)

The major advantage to this approach is that the information in the Cycle Driver tables can be entered by anyone with a working knowledge of the AUT and an idea of what should be tested. This means that the cycle and suite driver tables can be developed by test designers prior to system testing efforts and provided to the automation team, which subsequently develops the Step Driver tables. The effort required for the test designers to build their test tables can be minimized through the use of Nagle's VB (VisualBasic) Test Generator utility that allows the designers to enter the table values via a GUI rather than by typing them directly into the tables.

The DDE is already implemented. It just needs setup and installation, and then it is complete and ready to use—no local customizations are required to commence using it. Users need only to develop their test data to begin using the DDE. Only in cases where existing DDE functionality does not adequately provide solutions to given problems will users need to implement custom scripts, and these are not part of the DDE, but can be called by the DDE as necessary.

In the Archer Group methodology, the control data was included in the test scripts. In DDE, however, control data are placed in an application map containing GUI object recognition strings as well as other data. Action words invoke component functions, which are subroutines that act against the AUT. Test record type indicators are used that are similar to the Archer Group method. The application map is similar in function to the maps created by commercial automated tools such as Rational Software's TestFactory and Mercury Interactive's WinRunner. Nagle's framework includes an application mapping tool, the Process Container utility that comes with the DDE code.

The following are examples of DDE record types:

b = BLOCKID (defines the start of a named block within the input file)

c = DRIVER COMMAND (driver performs utility function other than test)

s = SKIPPED TEST (a test that is temporarily disabled [and logged as such]).

t = TEST (a test to perform; might be navigation, changing values, or verifying data)

The driver forwards the data record to the appropriate test script routine based on the record type.

Test data can be entered in the tables or contained in CSV files that the tables direct the test script routine to read and process. The Suite Driver test case example directs the DDE to process an application login via Step Driver with specific credentials:

T,  Login, ^id=myuserid, ^pw=mypassword

The Step Driver then processes the Login test table data to complete the operation:

t, LoginWin, UserIDBox, SetTextValue, ^id
t, LoginWin, PasswordBox, SetTextValue, ^pw

As you can see, no technical expertise is required to develop these tests. They are keyword based. Each record directs the test scripts to a specific location and tells it what action to take depending on the keywords it contains.

DDE Development Effort

The DDE setup reference document is located at groups.yahoo.com/group/RobotDDEUsers/files/Doc/sqabasic2000/DDEngineSetup.htm. This document is a must-read prior to installing the DDE and performing a pilot project. The pilot project requires a sustained effort, perhaps as much as 90 days. The project should be implemented specifically on a select subset of AUT features. At the end of the pilot period, the effort should be evaluated, and identified problem areas should be addressed.

Following the pilot, the remaining AUT feature tests should be automated, constituting a complete regression test suite. The actual time to develop the test suites should be estimated on the number of features and the number of test cases per feature for each AUT version.