What is Localization Testing? Example Test Cases & Checklist

Localization Testing

Localization Testing is a software testing technique in which the behavior of a software is tested for a specific region, locale or culture. The purpose of doing localization testing for a software is to test appropriate linguistic and cultural aspects for a particular locale. It is the process of customizing the software as per the targeted language and country.

The major area affected by localization testing includes content and UI.

It is a process of testing a globalized application whose UI, default language, currency, date, time format, and documentation are designed as per the targeted country or region. It ensures that the application is capable enough for using in that particular country.

Example:

1. If the project is designed for Tamil Nadu State in India, The designed project should be in Tamil language, Tamil virtual keyboard should be present, etc.

2. If the project is designed for the USA, then the time format should be changed according to the USA Standard time. Also, language and money format should follow USA standards.

The illustration below shows the same product being adapted for different locales, with the language, currency and formatting rules changing while the underlying build stays the same.

Why do Localization Testing?

The purpose of doing localization testing is to check appropriate linguistic and cultural aspects for a particular locale. It includes a change in the user interface or even the initial settings according to the requirements.

In this type of testing, many different testers will repeat the same functions. They verify various things like typographical errors, cultural appropriateness of UI, linguistic errors, etc.

It is also called “L10N” because there are 10 characters in between L & N in the word localization.

There is a commercial reason behind the effort as well. A mistranslated label or a date that reads 03/04 as March instead of April erodes trust in a market a team has already paid to enter, and those defects are found by a tester in the target locale rather than by GUI testing performed in English.

Localization Testing vs Internationalization Testing

The two activities are sequential rather than competing. Internationalization testing (I18N) confirms that the code base can accept any locale at all; localization testing (L10N) then confirms that one specific locale is correct.

Localization Testing (L10N)	Internationalization Testing (I18N)
Verifies that the product feels native in one target region	Verifies that the product can support many regions without redevelopment
Checks translated text, currency, date, time and cultural fit	Checks character encoding, string externalisation and locale-aware code
Runs once the translated build for that market exists	Runs first, before any text is sent for translation
Needs a tester or reviewer who knows the local language	Can be performed by the core team using pseudo-translated builds

Check this tutorial for a difference between localization and globalization testing.

How to do Localization Testing

For a typical localization testing, we set up build verification testing, Functional Testing, Regression Testing, and final sign-off.

1. Build verification testing is a small subset of functional testing, which is performed before QA starts with any detailed testing. It is close in spirit to smoke testing: the localized build is rejected quickly if the language pack fails to load at all.

2. Normal testing is the step to run the normal test cases and find log defects during execution.

3. Regression Testing is Defect regression process to ensure that the defect is fixed while there is no impact of fixed defects to surrounding areas.

4. Final Sign-off is to perform final checking on the build before delivery to the client.

Each phase is repeated per locale, not once for the product. A defect fixed in the French build has to be regressed in the German and Japanese builds too, because the same string resource is often shared between them.

Automation in Localization Testing

If the project is big and needs to test often, then we go for Automation Testing.

• Choose automation tool to write scripts.
• Take the scenario to be tested for localization strategy.
• Write scripts according to that.
• Collect the results and update the scenario as Pass/Fail.

Note: Selenium is one of the pioneering tools in this area. It is very feature-rich, however, it requires more technical knowledge to use.

Automation carries a limit worth stating plainly. A script can prove that a currency symbol changed and that no string is truncated, but it cannot judge whether a translation reads naturally or whether an icon offends. Machine checks handle the mechanical layer; a native reviewer still handles the linguistic layer.

Localization Testing Tools

Localization work draws on three different classes of tool, and most teams end up running all three.

• Functional automation frameworks: Selenium, Appium and comparable frameworks re-run the same suite against each locale build, which is where the bulk of repetitive verification happens.
• Translation management systems: Platforms that hold the string resources keep translators, developers and testers working from one glossary, so a term is not translated two different ways in two screens.
• Pseudo-localization utilities: These replace English strings with accented, lengthened placeholders before real translation begins, exposing hard-coded text and layouts that cannot absorb longer words.

Device and browser coverage matters just as much as the tool. Fonts, input methods and default locales differ across platforms, so the localized build has to be exercised on real target devices during mobile testing and across the browser set defined for web application testing.

Best Practices Checklist for Localization Testing

• Hire a localization firm with expertise in i18n engineering
• Make sure your localization testing strategy enables more time for double-byte languages.
• Ensure that you properly internationalize your code for the DBCS before extracting any text to send for translation
• Externalise every string into resource files first, so that no user-visible text remains hard-coded in the source.
• Run a pseudo-localized build early, because it exposes truncation and hard-coded text before translation money is spent.
• Reserve layout space for text expansion, since translations from English frequently run longer than the original label.
• Test right-to-left locales such as Arabic and Hebrew on real screens, where mirrored layouts and mixed-direction text fail most often.
• Maintain a per-locale style guide covering date order, decimal separators, address format, honorifics and tone.
• Have a native speaker review the finished screens, because cultural fit cannot be asserted by a script.

Two of those items depend on the platform rather than the language, which is why localized builds are usually scheduled alongside compatibility testing and configuration testing rather than after them.

Example Test Cases for Localization Testing

The table below gives a starting set of checks. Each row becomes a full test case once the expected result for the specific locale is filled in.

S.No	Test Case Description
1	Glossaries are available for reference and check.
2	Time and date is properly formatted for target region.
3	Phone number formats are proper to target region.
4	Currency for the target region.
5	Is the License and Rules obeying the current website(region).
6	Text Content Layout in the pages are error-free, font independence and line alignments.
7	Special characters, hyperlinks and hotkeys functionality.
8	Validation Message for Input Fields.
9	The generated build includes all the necessary files.
10	The localized screen has the same type of elements and numbers as that of the source product.
11	Ensure the localized user interface of software or web applications compares to the source user interface in the target operating systems and user environments.
12	Sorting and alphabetical ordering follow the rules of the target language, not the source language.
13	Right-to-left locales mirror the layout correctly, including navigation, icons and mixed-direction strings.
14	Keyboard input, spell check and search accept accented and multi-byte characters.

Advantages of Localization Testing

Following are the benefits of localization testing

• Overall testing cost reduce
• Overall support cost reduce
• Helps in reducing the time for testing.
• It has more flexibility and scalability.

Those savings come from catching locale defects once, centrally, instead of once per market support queue. Accessibility gains often follow as well, because the same discipline that keeps a layout intact under longer German strings also keeps it intact under enlarged text during accessibility testing.

Disadvantages of Localization Testing

Following are the challenges of localization testing

• Requires a domain expert
• Hiring local translator often makes the process expensive
• Storage of DBCS characters differ in various country
• A tester may face schedule challenges

The schedule pressure is the one most teams underestimate. Translation arrives late in the cycle by definition, so localization defects surface close to release, which is exactly when a layout change is most expensive. Planning the locale passes into the wider plan described in types of software testing keeps that squeeze manageable, and the general software testing introduction covers where the phase sits overall.

FAQs