Jimmy Collins

At my day job, we’re currently developing an automation suite to perform Build Verification Testing (BVT) and some basic functional testing on new builds coming into QA. This is a challenge in itself, but becomes even more difficult when you consider we currently release products across 28 distinct locales, including right-to-left languages like Arabic and Hebrew.

The drawback of this, is that we need to think of the bigger picture when writing an automation script/program. A program we develop to perform some action on an English build, on an English XP, may not perform as expected on say a German build on a German language version of XP.

Here are some general guidelines I’ve learnt along the way, to keep in mind when developing automation scripts/programs that you intend to run accross multiple languages/platforms.

1. Never hard code language dependent information

I’ve seen this a lot. Such information may be the expected title of an alert, that appears when the script performs some action. Hard-coding the expected alert title in English will cause the script to be useless on any other language. All these strings should be externalised in some way, even to a simple text file.

2. Never hard code paths to Windows system folders

Hard-coding these paths, such as the paths to ‘Program Files’ or the ‘Documents and Settings’ folder will cause your automation to fail on non-English platforms. The problem with these is that they may be localized on some environments. For example, ‘Program Files’ becomes ‘Programme’ on a German environment. If you need to use these paths, always use the Windows environment variables to retrieve the value, that way you can be sure the path will be valid for that platform.

For example, retrieving the path to the ‘Program Files’ directory (in VBScript):


Set oShell = CreateObject( "WScript.Shell")
strProgramFilesDir = oShell.ExpandEnvironmentStrings("%PROGRAMFILES%")


Where an environment variable is not available, you can usually find the path in the Windows registry with some Googling. For example, the ‘All Users\Application Data’ folder can be found at the registry location below on all Windows variants:


HKLM\Software\Microsoft\Windows\Explorer\Shell Folders\Common AppData


3. Don’t assume elements will always be in the same place

In controls such as drop-down menus, the order of the items will be different on each language. Assuming the same order will cause unexpected results or cause your automated tests to fail outright. Also, in RTL languages such as Arabic, the elements themselves will be in a completely different area on the dialog.

4. Never hard-code date formats

Always use the date and time formatting functions provided by the development language you are working with. Also, a common error I’ve seen is that developers assume the date seperator used is always the same, not true! This is a ‘-‘ (hyphen) on an English platform, whereas a ‘.’ (period) on a German environment.

For example,


31.12.2009 - Germany
31/12/2009 - Belgium
31-12-2009 - Ireland


5. Never use ‘record and playback’ automation tools

These are pretty useless in an environment where you are attempting to develop automation to run across multiple languages, with the obvious example being attempting to run a script on an Arabic build which you previously recorded on an English build, where the dialogs are mirrored and the elements are in completely different areas of the screen.

6. Create automation which is resistant to changes in the UI

A couple of string changes in the UI should not cause your automation to fail. Use Object ID’s where possible, as these will rarely change, and it’s easy to add a fix if they do.

Just adhering to the above simple guidelines should solve many of the common issues encountered when attempting to develop an automation suite to run across multiple languages.