Automating Localization Testing
Localization testing is challenging for software teams to automate, so many simply don’t do it. But, the juice is worth the squeeze–there is a myriad of benefits to multilingual Automated Testing!
From the controlled translation of items like actions, arguments, variables, and interface definitions, to locating UI elements, automating your localization testing can save a ton of time. And, it is not as difficult as people think, so long as you use the right methods. Paying attention to localization early–in test design, Automation architecture, and organization–can make a big difference in testing effectiveness and Automation maintainability. Today, we’ll walk you through the considerations for multilingual Automation for localization, as well as proposed testing strategies and use cases for Automation.
Language
The most obvious topic in localization you’ll have to deal with is language. Applications have many places where users interact with language. If the application is for international use, many texts might need to be translated, and to what extent depends on business considerations. Websites and mobile devices are among the most common cases where translation might be important. For websites it can be a challenge as they tend to be updated frequently. For major websites, there might be dozens or even hundreds of languages involved, and even a single language can vary between different regions (think Spanish in Latin America vs. Spanish in Spain). The style of the language to be used may also vary between less and more formal, the tone might vary, and linguistic nuances can make a huge difference in overall meaning. For example, a government website will generally use different words and phrases than a cool video game site for teenagers.
Some languages have their own quirks that need special handling. In German, a name like Schäfer can also be spelled as Schaefer. This would require a few tests, such as:
- Do both variations of the name work and refer to the same person?
- How does the application handle this?
- Does it recognize the same person, or make a duplicate record?
Data-Driven
A common approach is to keep phrases in separate files, for example one per language. Internally in the code, a text may be, “ERR_ZIP_CODE” in the file that supports American English; this then could become, “Please specify a zip code,” while in The Netherlands this could be, “De postcode is een verplicht veld.”
The testing of language goes through two main steps:
- Is the language correct?
- Is the correct text displayed?
The language test can be done in the applicable language file. You will need a language expert who understands what the intention of the text is, which might often need an external service provider. To verify if the correct text is displayed can be done fairly easily with the Test Automation Tool. Note that developers usually already have storage of strings that the code will be using, and you should try to use those for the testing, too; but, note that they may have variables in them, such as, “Welcome John,” and, “Welcome Pete.”
Locating UI Elements
Localization can also impact Automation. A common example is locating UI elements. If a test locates an “OK” button by its caption, it will break if in France that caption is changed to “Soumet.” The good news is that it is a small effort by developers can help out the Automation here. In most cases it is enough to add an attribute to the control that is not visible for the human user, but that the test tool can detect. In desktop applications, using platforms like Java Swing or .Net, assigning a value to a “name” property usually suffices. Using “Accessibility Name” can also be an option. In web page elements, an attribute like “qa id” can help greatly (the “id” attribute could also be used, but is often re-assigned frequently over time). Attributes like these rarely change over time, and localization has no impact on them.
UI Behavior
An even more subtle issue for Automation is different behavior. In a different locale, the navigation of the UI might be different. For some locales an extra field will be added for a middle name, or, like in various countries in Europe, more than one middle name can be common. The localization of such a field might fail simply because the field in that locale doesn’t exist. Much of this complexity can be mitigated by system design, like allowing a middle name field to have more than one name, but can also have an effect on the Automation. Another example of an effect on Automation navigation is whether the time is expressed in 24 hours or in 12 hours, with AM/PM, needing an extra control/element in the UI.
Page Objects
In web applications, consider the use of Page Objects. You can define one for each page in the application, and they can have methods that can shield localization details from a calling automated test case. Apart from differences in texts and values, localization can also impact system behavior. For example, a US address has state and zip code fields; not every country has those, so the Automation should not try to enter them, nor do any processing on them like verifying whether a zip code can exist for a given state.
Variations
TestArchitect has a feature called “variations,” with extensive abilities to deal with environmental properties that most tests don’t care about, but that can break the Automation. This tool may help with doing the heavy lifting of translating, but as with any tool, it’s important to remember it is a tool–not a solution. It will reduce the workload for testers to concentrate their efforts on the more important, human-based testing around localization.
Creative Tooling
Sometimes tooling can help set up localization testing. The screenshots below show a small tool to apply Action-Based Testing in an international project. An offshore team can use English language actions to create test cases. The tool can then translate these, back and forth, to make the tests more comfortable to read. Even more relevant is the use of variables.
They will have a Japanese value, and their name is the same as that value. But, the tool can replace this name with a suitable translation, so the team can use them in tests.
What “suitable translation” means should be decided by a “language owner,” who is typically a native speaker who creates or verifies the data files with translations this tool is using.
Summary
Localization is a challenging topic. Paying attention to it early in test design, Automation architecture, and organization can make a big difference in testing effectiveness and Automation maintainability.
He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations. Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.