In an industry where getting software in front of global audiences quickly is vital, your applications need to behave the way you want them to in every setting. That means investing in software localization testing.

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, and sorting problems. 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.

Test Plan Development
Localization testing requires very detailed test plans in order to be successful. Test plans (test scripts) have to be designed in a way that displays as much of the tested UI as possible. Some screens may be displayed only as the results of changing software settings to specific values. Designing test plans like this is a time-consuming task, but our team stands ready to help you with it.

Expert User Testing
Software products may require complex setups or additional hardware. It may not be easy to reproduce the right environment for localization testing, and the best option may be to involve expert software users in the localization process.

Localization Testing
Make sure your localized content is right for your target audience with our additional testing services. Your software will not only meet your initial business and technical requirements, but the look and feel of your software will also match local expectations.

Linguistic Testing
Linguistic testing is focused on the following areas:

• Translation completeness
• Spelling, grammar, punctuation, style, consistency
• Terminology

Defect Analysis Services
Not every localization defect is caused by mistranslation. A thorough analysis of reported defects can reveal more complex localization and internationalization issues.

Why Argos?

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.