.................................................................................................................Main Page / Back to Execution Patterns / Back to Test Automation Patterns

Pattern summary

Declare all the GUI-Objects in the Object Map of the test automation tool. (Or define your own if appropriate.)

Context

This pattern is appropriate if you want your test automation to be long lasting, because your scripts will be easier to read and less dependent on the current tool.
This pattern isn't needed if you only write disposable scripts or if your application is exceptionally stable, with object names never or hardly ever being changed.

Description

Declare all the GUI-Objects in the Object Map of the tool (note: this may also be called a GUI map or Object Repository). You can then write your scripts using standardized names. The scripts will be more readable and if you have to migrate to another tool you will not need to change the scripts to allow for new names even if tools seem never to use compatible naming conventions.

Implementation

This is one way to implement TOOL INDEPENDENCE, as your tests will be one layer removed from the specific names in the software.
Some suggestions:

Ask the developers to use unique names to define the GUI-Objects. If the same objects are used over a number of different screens (object-oriented inheritance) it may be useful to add the screen name to the object name for better recognition.
When driving the GUI avoid using pixels, screen coordinates or bitmaps to identify graphical objects. Screen coordinates can vary from machine to machine, from operating system to operating system or from browser to browser. Also changes in the Software under Test (SUT) can mean different positions for the GUI-Objects, so your scripts are more likely to break.
If the SUT runs in different countries, you must also avoid using text labels if you don’t want to write new scripts or have to have a separate Object Map for every new language!
If you can't use the tool's facilities, you can make your own "translation table", in which you have the names you will use for the tests in one column, and the current name used by the software in another column. Then if the software names change, you only have to update your translation table and all your tests will continue to work.

Some suggestions for object naming:

Internal developer name: if the developers follow a style guide it can be useful to use the same names. In this way you also have the advantage of being able to communicate with the developers in their own “language”
Label on screen: using the labels on the screen makes it easier for testers to follow what happens in the script
Functional term: using the correct terms is a useful way to document what the script is supposed to achieve

Potential problems

This approach might be perceived as an unnecessary additional complication, but it is needed to gain a level of abstraction from the tool.

Issues addressed by this pattern

NON-TECHNICAL-TESTERS
OBSCURE TESTS
TOOL DEPENDENCY

Experiences

If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!
Examples
Seretta:
In my company we use a variation of KEYWORD-DRIVEN TESTING that enables us to write scripts that ensure TOOL INDEPENDENCE if we take care to standardize the names of the required GUI-objects. We have mapped the same objects to the same names in the tools that we are currently using (QARun and TestComplete). This is necessary because otherwise the tools would use a proprietary naming convention and our scripts wouldn’t be tool independent any longer.

To show how this works, here is an extract from one the scripts that we use to test our own test automation framework:

…….
 
 GOTO,FTestSuite
 
 INPUT,ComboBox,cboPriority,<Priority>
 
 INPUT,ComboBox,cboTestType,<TestType>
 
 …….

FTestSuite, cboPriority and cboTestType are mapped to the same names in both tools. In this way we don’t have to change our test scripts when changing the tool. Since the GUI-Objects are called over and over it is definitely cheaper to map the names again than to update all the test scripts. Another advantage is that in this way one can use more then one tool concurrently and with the same scripts!

Freddy Vega:
A good example of an abstraction layer is an Object Repository that maps GUI elements (of any type) to human readable names. For example say you have a an application with a login screen that has three elements: Login Name, Password and a Login Button, under the hood, however, these things may be called something entirely different e.g. login_name_field1, password_field2 and login_button3 respectively. These three items, if used directly in a test script will not only make the test script harder to read for non technical folks, but also more brittle and less maintainable. If instead we add this to an object map it may look like this (for a web application):

element_name	locator_strategy	element_type	name	screen_id
login_name_field1	id	input	Login Name	login
password_field2	css	input	Password	login
login_button3	id	button	Login	login

We can now in our test easily reference human readable names that will likely never change vs referencing element identifying information within the test script. Every time the element's info changes all we need to do is update our object map rather than all the test scripts that reference that login page.

................................................................................................................Main Page / Back to Execution Patterns / Back to Test Automation Patterns
B3 5

OBJECT MAP

Contents