Once an application is internationalized, the engineering effort required to maintain its localized versions, and to localize it to new languages, is drastically reduced. However, the same is not true for UI localization testing. In this blog post I describe common localization bugs, and the main challenges involved in finding them.
In Part 2 of this post, I will describe how to effectively overcome these challenges using Visual Test Automation tools.
Localization is the process of customizing a software application that was originally designed for a domestic market so that it can be released in a specific foreign market.
This process usually involves substantial changes of the application’s UI, including the translation of all texts to the target language, replacement of icons and images, and many other culture, language, and country specific adjustments, that affect the presentation of data (e.g., date and time formats, alphabetical sorting order, etc.). Due to the lack of in-house language expertise, localization usually involves in-house personnel as well as outside contractors, and localization service providers.
Before a software application is localized for the first time, it must undergo a process of Internationalization. This process often involves an extensive development and re-engineering effort which goal is to allow the application to operate in localized environments and to correctly process and display localized data. In addition, locale-specific resources such as texts, images and documentation files, are isolated from the application code and placed in external resource files, so they can be easily replaced without requiring further development efforts.
Once an application is internationalized, the engineering effort required to localize it to a new language or culture is drastically reduced. However, the same is not true for UI localization testing. Every time an application is localized to a new language, the application changes, or the resources of a supported localization change, the localized UI must be thoroughly tested for localization and internationalization (LI) bugs. Common LI bugs which can be detected by testers that are not language experts include:
- Broken functionality – the execution environment, data or translated resources of a new locale, may uncover internationalization bugs can prevent the application from running or break some of its functionality.
- Untranslated text – text appearing in text fields or images of the localized UI is left untranslated. This indicates that certain resources were not translated or that the original text is hard-coded in the UI and not exported to the resource files.
- Text overlap / overflow – the translated text may require more space than available in its containing control, resulting with the text overflowing the bounds of the control and possibly overlapping or hiding other UI elements.
- Layout corruption – UI controls dynamically adjust their size and position to the expanded or contracted size of the localized text, icons or images, resulting with misaligned, overlapping, missing or redundant UI artifacts.
- Oversized windows and dialogs – multiple expanded texts and images can result with oversized tooltips, dialogs and windows. In extreme situations, expanded dialogs and windows may only be partially visible in low screen resolutions.
- Inadequate fonts – a control’s font cannot properly display some characters of the target language. This usually results with question marks or glyphs being displayed instead of the expected text.
Other common LI bugs which can only be detected with the help of a language expert include:
- Mistranslation – translated text that appears once in the resource files, may appear multiple times in different parts of the application. The context in which the text appears can vary its meaning and require a different translation.
- Wrong images and icons – images and icons were replaced with wrong or inappropriate graphics.
- Text truncation – the translated text may require more space than available in its containing control, resulting with a truncated string.
- Locale violations – wrong date, time, number and currency formats, punctuation, alphabetical sort order, etc.
An unfortunate characteristic of LI bugs, is that they require a lot of effort to find. To uncover such bugs, a tester (assisted by a language expert) must carefully inspect each and every window, dialog, tooltip, menu item, and any other UI state of the application. Since most of these bugs are sensitive to the size and layout of the application, tests must be repeated on a variety of execution environments (e.g., different operating systems, web browsers, devices, etc.) and screen resolutions. Furthermore, if the application window is resizable, tests should also be repeated for various window sizes.
There are several other factors that contribute to the complexity of UI Localization testing:
- Lack of automation – most of the common LI bugs listed above are visual and cannot be effectively detected by traditional functional test automation tools. Manual inspection of the localized UI is slower than with a non-localized UI because it is unreadable to the tester.
- Lack of in-house language expertise – since many of the common LI bugs can only be detected with the help of external language experts, which are usually not testers and are not familiar with the application under test, LI testing often requires an in-house tester to perform tests together with a language expert. In many cases, these experts work on multiple projects for multiple customers in parallel, and their occasional lack of availability can substantially delay test cycles and product releases. Similarly, delays can occur while waiting for translation of changed resources, or while waiting for translation bugs to be fixed.
- Time constraints – localization projects usually begin at late stages of the development lifecycle, after the application UI has stabilized. In many cases, testers are left with little time to properly perform localization tests, and are under constant pressure to avoid delaying the product release.
- Bug severity – UI localization bugs such as missing or garbled text are often considered critical, and therefore must be fixed and verified before the product is released.
Due to these factors, maintaining multiple localized application versions and adding new ones, incurs a huge overhead on quality assurance teams. In Part 2 of this blog post, I will show how Visual Test Automation tools can be applied to UI localization testing, eliminate unnecessary manual involvement of testers and language experts, and drastically shorten test cycles.
Yeah! Take me to part 2 of this post.