An Introduction to Software Localization Testing
In an industry where getting software in front of global audiences is paramount, investing in internationalization and localization can help make sure applications behave the way you want them to in every possible culture and setting.
First things first – internationalization (or I18n for short) is the process that lets your product to be translated for global markets. The first step in I18n is to find any issues that may exist, which can be done either by enabling your code (code auditing) or by internationalization testing. The difference between the two approaches comes down to a matter of cost and time, with internationalization testing typically being much cheaper.
Testing typically involves running the source application on a tester’s locale stack, which can test operating systems, browsers, and prerequisites/optional software to test against, just for starters. The next step is code refactoring, where the issues that were picked up are acted on and the code and existing development guidelines are improved.
All around the world
Once your app or product is internationalized, it’s time to localize it into the selected target languages. If your product is “globalization ready” by being properly internationalized, it will still work when it’s translated into other languages and run with different regional settings. If that’s the case, the product is ready for functional localization (L10n) testing. This usually includes comparative testing against the source product, and it can highlight defects, truncations, error message problems, sorting problems, and other issues. When this step is finished, we recommend translation verification testing (TVT) by a native speaker.
All this testing will involve test plans and test scripts being developed or a subset being re-used from the English source product. The secret to successful testing is to leverage the knowledge from I18n testing to L10n testing to TVT, and the point of all forms of testing is to reduce the risk of a product failing in the marketplace. Catching problems before release dramatically reduces support costs – the cost of fixing i18n issues after releasing localized software is 7-10 times higher than fixing them during i18n testing.
The Argos way
We typically propose a core testing team to review available reference materials and familiarize themselves with your product, and we also recommend that localization testing services be conducted on the localized product versions by the testing core team before any TVT happens.
All testing methods can be combined into a customized approach that suits your needs and release cycles. We’ll assign a dedicated testing team to your project and document a bespoke project test plan that includes project goals, an agreed scope, a testing approach, a test case development (if needed), milestone delivery dates, highlighted risks (and appropriate contingencies), and reporting to agreed standards.
To learn more about how we can help you take your software worldwide, get in touch with us.