Localization Testing - Speaking the language of your customers
In order to target a global market, software product developers need to step out of their native locale and develop their product for a global market. This asks for Internationalization and Localization of the product. As easily said, localized product is a product with UI translated to native language. However, Localization is not just about translating all strings but also making sure the product conforms to a local user experience. This in turn calls for Internationalization, or developing a product that can be adapted to local usage which is a combination of product functionality on the local environment, acceptance of localized character set, keyboard/input styles, time zone etc
As intricate the process of localizing a product may sound, it only constitutes half of the story. The other half lies in testing this localized version of the product on every single locale/culture that it supports. This testing of a localized and internationalized product is termed as Localization Testing. This effort not only involves testing of proper translation but also relevant functional verifications. This would involve verifications ranging from simpler ones like checking for text truncation to much complex functionality like support for Unicode character sets, checks for sorting rules etc.
With so many tests to be conducted per locale, management of the whole process becomes much critical. Managing hardware and software to simulate native user environment, building a team of skilled testing engineers who appreciate and understand what would break in localized software, and above all getting to a release-ready product within the allocated time and budget can be a daunting task for any team not prepared for it.
Localization Testing, unlike traditional functional testing, calls for much vast set of hardware and technical skill set. Not only that but every aspect of test management from test case optimization to test metrics adorns a different meaning in the context of Localization Testing. For example, with a localized product the bug tracking tool now would need to have a way to track bugs on a per locale basis. Now, there are many ways to do this, a simple keyword based extension identifying all locales on which the bug exists is one option. Does this approach suffice? Does this extension in any way twist the project metrics?
Another example is in the process of test execution. Localization testing for most of the common functionalities calls for a defect, when found, to be checked on the language that the product was built on in the first place (in most cases English) and in some cases in all supported locales. However, this calls for an additional effort. Should this be always done? Can this be optimized?
In terms of resources, localization testing labs needs to be equipped with hardware and software to simulate any and every native user action and experience on a localized product. A product supported on 22 languages, two platforms (Win/MAC) would need at least 48 machines still with the constraint that a combination of the machine/locale can only be used by a single person at a time. This problem is solved by smart use of virtualization. Can every test case of the product be tested on a virtual machine?
We at QA InfoTech have developed insightful answers to all such questions as raised above based on our long experience of working on large product localization projects. We have developed large teams where in people exactly understand what Localization Testing calls for. Our QA Managers have long experience of juggling and optimizing resources without compromising on quality or project deadlines. Our labs and infrastructure provide the right support for our teams to be best productive.
Do not hesitate to write to us if you are a project manager having difficulties with your Localization Testing projects, we would love to hear from you.
