In an industry where getting software in front of global audiences is vital, your applications need to behave the way you want them to in every possible culture and setting. That means making investments in internationalization and localization.
Internationalization (I18n) enables your product to be translated for global markets. The first step in the I18n process is to detect any issues that may exist, which can be done either by enabling your code (code audits) or by internationalization testing (the difference between the two is cost and time, with internationalization testing typically being much cheaper.) Testing involves running the source application on a tester’s locale stack, which can test operating systems, browsers, and prerequisites/optional software to test against, 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.
Once your product is internationalized, you can localize it into the selected target languages. If your product is “globalization ready” by being properly internationalized, no functions will be broken once it’s translated into other languages and run with different regional settings.
At this point, the product is ready for functional localization (L10n) testing. This can include comparative testing against the source product, and it may highlight defects , truncations, error message problems, sorting problems, etc. When this is finished, we recommend translation verification testing (TVT), which is normally conducted 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 testing.
The point of all forms of testing is to reduce the risk of a product failing in the marketplace. Catching problems before release will dramatically reduce support costs – the cost of fixing i18n issues after releasing localized software is 7-10 times higher than fixing it early in the process during i18n testing. Code is written in English in English-speaking countries and uses English language rules, which need to be changed for other languages and locations. Concatenating 3 English error messages into one error message will not necessarily be good for a lot of other languages.
When you sit down to work with us, we typically propose a core testing team to review available reference materials and familiarize themselves with the product. If a product build and existing test-cases are available, our QA team will get to know the product and practice navigating it. We 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, and it’s also important to control versioning for all products and strictly define the test setup while enabling different OS/browser configurations depending on your field feedback history.
Based on your feedback, 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.
- Partnership approach
- Lower costs
- Customized solutions
- Faster time-to-market
- Lower risk of defects