Download: Best Practices in Localization Testing
Localization testing has become an indispensable component of just about every software localization endeavor. Just like localization per se, it has experienced major developments since it emerged as a recognized standalone testing type more than 20 years ago. It has also faced similar challenges.
This article was published in MultiLingual Computing magazine #109.
If trends such as reducing overall costs, automating "wherever possible," shortening time frames (think reducing the number of test passes in testing) and an overall shift to outsourcing sound familiar to you from the software translation side of things, you will feel immediately comfortable in the realm of testing, too. Let's take a closer look at where localization testing stands today, the current issues, touch points and synergies that exist between localization and localization testing.
The Role of Localization Testing
Localization testing follows after product localization and is performed to ensure that the localized product is fully functional and linguistically accurate and that no issues have been introduced during the localization process. Issues introduced as a direct result of localization may be linguistic or terminological in nature; may be related to the graphical user interface (GUI) and its cosmetic look and feel; and may break or compromise the functionality of the localized product.
These problems may be introduced simply because software translation normally takes place using tools "outside" of the actual running software application. Individual GUI elements typically pose few problems, but the general string table content may be more challenging, especially with the time pressures frequently imposed on localizers.
Much effort often goes into providing localizers with as much information as reasonably possible about the context in which particular localizable software strings may appear. But the fact of life is the contextual information is typically far from complete, even more so if particular strings appear dynamically in multiple user situations or in different parts of the software interface.
What Capabilities Are Needed
In the past, localization testing has been frequently confused with language or linguistic testing and the assumption was that primarily native speakers or at least advanced-level speakers of the given target language (TL) should be involved. That is no longer the case today. It is now common practice to separate the truly language-specific testing activities, which look at aspects such as in-context language quality or consistency in the running build, from those where only a general knowledge of the characteristics and issues of the particular language is required.
There has always been the dilemma over which is more important: the engineering capabilities of the tester and his or her product knowledge, or his or her linguistic and language background. In practice, it is not easy to get the best of both worlds here and to build, develop and maintain a balanced testing team composed of native TL speakers who also possess excellent engineering capabilities.
To continue reading this article, please complete this simple form below and download the full PDF version.