What You Need to Know About Localization Testing [Cliff Notes]
Click here to close
Click here to close
Subscribe here

What You Need to Know About Localization Testing [Cliff Notes]

What You Need to Know About Localization Testing [Cliff Notes]

Localization TestingIf you are new to localization, or if you consider yourself a non-technical localization professional, then this blog series is for you.

Any type of testing in localization is a fundamental step meant to catch problems that will impact the adoption or effectiveness of your software product or website in market.

Although functional, localization and linguistic testing sometimes overlap, they are distinct testing services that require different resources. An accurate and precise understanding of what each entails is important. The past blog was about functional testing, and I will write about linguistic testing later, but for now, let’s focus on localization testing.

Localization testing

Once functional testing is complete, localization testing adds languages to the mix. It makes sure that the localized versions look, feel, function and behave exactly the same as the source version, and that no problems arose as part of the localization process.

Localization testing is usually performed by testers who don’t speak any of the tested languages. A tester will always have the source (usually English) application at hand for reference and they perform the same test cases on both source and localized application simultaneously; as a result, a tester who does not speak Japanese (for example) can successfully execute a whole suite of test scripts on a Japanese product and validate it behaves the same as its English reference.

Localization testing will find problems such as:

  • Non-functional features
  • UI and layout defects like misalignment, overlap, extra or missing controls
  • Scrambled dialog boxes and web pages due to the dynamic assembly of content
  • Errors in concatenated strings and in strings composed using placeholders
  • Truncations and text bleeding issues caused by text expansion
  • Problems in a tested system’s acceptance of all extended characters 
  • Issues with handling files with extended characters in their file names and paths
  • Problems with the search and replace function
  • Sorting issues related to that specific language’s alphabet
  • Duplicated or missing hotkeys in Windows applications
  • Incorrect date, time and calendar formats
  • Errors in currency conversions and monetary symbols
  • Incorrect metric conversions, numeric formats, separators, and negatives

Localization testing is completed by localization savvy resources who have technical expertise, though not necessarily at the level of functional testers. They:

  • Have some technical background
  • Understand issues inherently brought into software by its localization
  • Recognize key differences in languages sufficiently to spot the issues described above

What comes after functional testing?

Having tested functionality on the builds of your localized product you would then move on to a test of the language quality. In this pass, a linguist would review the text in context to spot language errors.

Why is localization testing important in localization?

Why would you have spent all the time and money on localization only to release a product that doesn’t work in the target language?  If the localized product is full of bugs – problems in functionality – then you will have to spend MORE time and money to fix them. Your product release will probably be delayed and if you miss bugs from being in a hurry, your users will complain or worse, not use your product. They are almost always going to be a few issues in your product after localizing it, but fixing them could be easy and quick, versus painful and costly.

If you have discovered functional errors after localization what impact did that have on your product release?

Look for the next part in this blog series that will explore linguistic testing.


Thanks to my Solutions Architect colleague and testing expert Jiri Machala for reviewing and contributing to this blog post.