Automating Localization Testing

[article]
Summary:

Wouldn't it be great if you could record automated scripts in the original program language (most commonly, English) and then run those scripts in the languages you have translated? This article examines translation issues, and whether automated-localization results will pay back the initial investment of time, money, and training.

Automation Programs
Automating localization testing can be very tricky. Most automation programs include a Scenario Recorder/Playback utility. This will be useless for localization testing for these reasons:

  • Some of the automation programs will record by default mouse clicks on the screen, by position. The position of the items in localized software is different from the US software, because most language strings will be shorter or longer than English strings. So the next sentence (from a common automation program) will only work in the original US software:

Play "{Click 278, 34, Left}"

  • The second most common default uses text. Obviously, this will not be useful for localization testing purposes. For instance, if we are checking a Web site, in some instances we would like our automated script to navigate to the home page. Most automation programs would write something like this:

WebLinkClick ( http://www.bowneglobal.com, "Home")

The Spanish string for Home is "Inicio," and the French is "Accueil," so that sentence will never work in the Spanish or French environments, not to mention any Asian language (although it would work for German or Italian, as they also use "Home").

So we will need to forget about the "recording" and any other default and start writing the scripts line by line, making sure what we write can be "understood" in any language. There are several ways to do this:

a) Ordinal Position

The first approach would be the ordinal position of the objects. Ideally, the items are placed in the same ordinal sort in every language. Let's check the main menu of any Microsoft application: File-Edit-View-Insert-Format. Any other language will translate those terms, but the ordinal sort will be the same. So, while this command will not work:

wmenuselect ("Edit")

this one will work in any language:

wmenuselect (_ord (2))

Do we have a definitive solution? Unfortunately not. We have a solution for menus and submenus, in a very controlled environment, and maybe some dialogs, but this approach will not work in other dialogs. For example, check these screenshots from Microsoft Outlook (New Contact-Insert-Item):

Let's say we want to click in Calendar. According to the successful test we wrote for the Edit menu, we would type something like this:

WtreeItemClk (_ord(1))

This would open the Calendar in the US machine, but the Inbox folder in the Spanish environment.

As the elements are alphabetically sorted, Calendar is ord (1) in the US, but it is ord (4) in Spanish, and the order will be different for French, Russian, and German, etc.

b) ID Numbers

We need to go one step further: Recording doesn't work, text references are also a waste of time, and ordinal position only works sometimes. We need to check the ID numbers of the objects. ID numbers always work: Calendar, as a tree object, will have a unique ID for any language, so we can find that ID out with any Window Information utility and we would write:

WtreeItemClk (_id(83411528))

This will work. But again, do we have a definitive solution? And again, the answer is no.

First of all, not all the objects have a unique ID. Some objects are just containers for other objects, so they are not identified by a unique ID. Also, assigning IDs to objects is not fully automatic during development. And you cannot trust that all the developers took their time to assign unique IDs to the objects they were creating.

There is even one more problem: the ID can be just a number, or a whole string containing a lot of information, from the main window to the deepest object information. This is

Pages

About the author

Jose M. Ladero's picture Jose M. Ladero

Jose M. Ladero is a senior test lead based in Madrid, Spain. He has spent the last nine years in various capacities as manual tester, databases engineer, test automation specialist, and test team lead, in Spain, the United States, and Ireland.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!