Software QA FYI - SQAFYI

Using GUI-based Automated Test Tools to Test Legacy Applications

By: Keith Zambelich

Sr. Software Quality Assurance Analyst Automated Testing Evangelist

Introduction: A great many companies today are currently running numerous legacy (character-based or "green screen") applications on a variety of platforms (Mainframe, AS/400, Tandem, Stratus, etc.). Furthermore, there is an increasing trend toward integrating these systems with front-end GUI, Internet, and Intranet applications, and using the Mainframe and AS/400 type computers for back office processing. Some companies are using AS/400s as Internet and Network servers. Most companies are opting to access their Mainframe (etc.) computers via Terminal Emulation from PC Workstations, rather than use "dumb terminals".

Many of these companies desire to automated their testing processes, but find the selection of a test tool that will meet all of their testing requirements difficult, at best. One tool may be better at testing legacy applications, while another is better at testing GUI applications, and still another is better at testing Internet/Intranet applications. What is sought is a tool or suite of tools that can be used to automate testing across the enterprise, as the prospect of training Q/A and technical staff in the use of several different tools from different manufacturers is daunting, if not completely unrealistic.

There are several automated test tool manufacturers that provide enterprise-wide testing solutions. The most notable of these include Mercury Interactive, Inc., Segue Software, Inc., Compuware Corporation, and Rational Software Corporation. This article is confined to describing my approach to configuring Mercury Interactive's WinRunner® automated testing tool for optimal use in testing legacy applications, as I am most familiar with this tool. The concepts expressed, however, can be applied to other automated test tools.


Learning the Screens: Regardless of the tool and the methodology (record/playback, scripting, etc.) being used, the first thing one must do is to have the tool learn all of the screens in the application under test. Automated Test Tools such as WinRunner®, LiveQuality® (Segue), and SQA Suite® (Rational) were all initially developed as GUI test tools. All such tools need to "learn" each window (screen) in an application and each object within that window. Using Terminal Emulation allows the tool to treat the character-based screen as a window, and the fields within each screen as objects. The tool learns the screen and the fields within the screen and places this data in a Screen / Window Definition File. For WinRunner®, this file is called the "GUI file".

The problem is that in actuality, character-based screens are not windows, and fields are not objects. Legacy application screens are designed and defined by using an X-coordinate, a Y-coordinate, and a length value for each field within the screen. GUI-based automated test tools, however, are usually not initially configured to learn character-based screens in this way. Normally, they are configured to identify fields using either "attached text" (text to the immediate left of the field), or index / location value (relative position on the screen). Neither of these configurations work well for character-based screens.

Attached Text doth not a Label Make: Using "attached text" as a means of field identification can create all sorts of problems. First of all, some applications are written such that the labels change, based on certain conditions. If that occurs, the field will no longer be recognized. More importantly, all fields do not have labels. Consider the following example: Customer Name: ___________________ _ _______________________

What this actually represents is: First Name Middle Initial Last Name.

What is learned is: Name_0 text = "Name" index = 1, Name_1 text = "Name" index = 2, Name_2 text = "Name" index = 3, where "Name" is taken as the "attached text" of each field. What happens if the fields are learned while data is being entered?

Customer Name: Joe

Now what is learned is: Name_0 text = "Name", Joe_0 text = "Joe" index = 2, Joe_1 text = "Joe" index = 3. This time, the "attached text" of field_1 is "Name", while fields 2 and 3 have the "attached text" of "Joe". Text, after all, is text. Can you see how this could cause a problem? What happens when the first name changes?

Using Index / Location Will Drive You Batty: All right then, lets not use "attached text" and just use the field's relative position (Index or Location). Now, using the same example: Customer Name: ___________________ _ _______________________

What is learned is: Name_0 Index = 1, Name_1 Index = 2, Name_2 Index = 3, where each field has a unique value. This looks like it will work. Unfortunately, many character-based screens contain "hidden fields" that only display under certain conditions. Consider this example:

Field_0: Field_1:

Field_2: Field_3:

When these fields are learned, they have index values of 1 thru 4 respectively. So far, so good. But when the next record is read using this screen, conditions exist such that the following is now displayed:

Field_0: Field_1: Field_A: Field_B:

Field_2: Field_3:

Fields A and B are now displayed, but were not learned in the original screen. Field_A now has an index value of 3, Field_B now has an index value of 4, and Fields 2 and 3 have values of 5 and 6 respectively. The script running is entering data into Field_2 which was defined as having an index value of 3 - but the field that has the index value of 3 is now Field_A. Guess where the data goes.

There Is A Solution: In character-based applications, fields within screens are developed using an X-coordinate, a Y-coordinate, and a Length. The way to make this work is to configure the tool to learn field attributes as follows: Obligatory attributes: X, Y Optional attributes: Length

Now let's apply this to the previous example:

Field_0: Field_1:

Field_2: Field_3:

These fields will be learned as follows: Field_0: X = 5, Y = 10 Field_1: X = 5, Y = 20 Field_2: X = 6, Y = 10 Field_3: X = 6, Y = 20

(Note that "length" is not learned in this example, as it is not necessary. In fact it would never be necessary unless a field with a different length was displayed at the same location under some certain condition. In that case, both fields could be learned, as they can be differentiated by length.)

Now when the "hidden" fields are displayed, the fields that have been learned are still properly identified, and the script will not fail.

Field_0: Field_1: Field_A: Field_B: Hidden data

Field_2: Field_3:

Since "attached text" was not used, data displayed in Field_B will not affect the recognition of Field_2. Data which is supposed to be entered in Field_2 will be entered in Field_2 no matter what else is displayed on the screen.

The one disadvantage to this method, is that if a field is added to a screen, or some of the fields are moved down a row, then a number of fields will need to be redefined. All this takes, however, is editing the Screen Definition or "GUI" file and changing some coordinates. You don't need to "re-learn" the screen. Typically this takes about 10 minutes.

The advantages, however, should be obvious, including the fact that by using this method, the screen does not have to be developed yet. The definition for the screen can be keyed-in using the field specifications. This can also be used to test whether or not the programmer developed the screen according to the specs or not.

Full article...

Other Resource

... to read more articles, visit

Using GUI-based Automated Test Tools to Test Legacy Applications