Topic: Globalization Testing

 

Introduction

The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.
 

 

Proper functionality of the product assumes both a stable component that works according to design specification, regardless of international environment settings or cultures/locales, and the correct representation of data.

Contents:

• Gobalization-Testing Plan

 

• Create the test environment

 

• Execute Tests

 

Decide the priority of each component

To make globalization testing more effective, assign a testing priority to all tested components. Components that should receive top priority:

• Support text data in the ANSI (American National Standards Institute) format
• Extensively handle strings (for example, components with many edit controls)
• Use files for data storage or data exchange (e.g., Windows metafiles, security configuration tools, and Web-based tools)
• Have had many globalization problems in the past

 

 

Select a test platform

So, which operating system (OS) should you use for your international testing platform? The first choice should be your local build of Windows 2000 with a language group installed. For example, if you use the U.S. build of Windows 2000, install the East Asian language group. This combination gives you complete international support for the language selected without imposing requirements on the testers' language skills.

Even if you target a broader range of operating systems, Windows 2000 should be your primary test platform. Earlier operating systems do not give you the same flexibility with local settings and native support for the broadest range of languages and cultures/locales.

You may also use other platforms that differ from your local build of Windows 2000:

• MUI (Multilanguage User Interface) Windows 2000 — especially useful if your code implements multilingual UI and it must adjust to the UI settings of the OS. This approach is an easier implemented alternative to installing multiple localized versions of the OS. To further enhance multilingual support, Microsoft offers a separate Windows 2000 MultiLanguage Version, which provides up to 24 localized language versions of the Windows user interface. For more information, see Multilanguage User Interface (MUI).
• Localized build of the target OS — German or Japanese are good choices. Remember it might be harder to work with them if you do not know the operating system's UI language. This approach does not have significant advantages over the solutions above.

Most globalization problems found by testing occur when East-Asian-languages support is active or when the OEM code page differs from the ANSI code page for a given culture/locale. For example, you can select the following cultures/locales in the U.S. build of Windows 2000 to test for potential globalization problems:

• Japanese
• German
• A combination of both (one selected for the System locale and another for the User locale) whenever possible to cover multilanguage support

 

Create the test environment

To perform globalization testing, you must install multiple language groups and ensure that the culture/locale is not your local culture/locale. As mentioned above, executing test cases in both Japanese and German environments, and a combination of both, can cover most globalization issues.

Essentially, the steps to create a world-ready test environment using Japanese and German environments are:

 

 

1. On your local build of Windows 2000, install Japanese (or any other East-Asian region) and German language support, if not already installed (the U.S. build of Windows 2000 installs German language support by default).
2. Set the culture/locale on the test machine to different cultures/locales from your local culture/locale (Japanese or German).
3. Set up a distributed network with a mixed environment of your local build of Windows 2000 systems with some set to the Japanese culture/locale and others set to the German culture/locale.

Testing with Japanese as the system default culture/locale verifies double-byte character set (DBCS) handling in ANSI (non-Unicode) components. Testing with German as the system default culture/locale ensures that ANSI and OEM code pages are handled properly when text conversion is required. Having a distributed mixed network environment verifies that data can be successfully passed between different cultures/locales.

Execute Tests

Execute tests

After the environment has been set for globalization testing, you must pay special attention to potential globalization problems when you run your regular test cases:

 

 

• Put greater importance on test cases that deal with the input/output of strings, directly or indirectly.
• Test data must contain mixed characters from East Asian languages, German, Complex Script characters (Arabic, Hebrew, Thai), and optionally, English. In some cases, there are limitations, such as the acceptance of characters that only match the culture/locale. It might be difficult to manually enter all of these test inputs if you do not know the languages in which you are preparing your test data. A simple Unicode text generator may be very helpful at this step.

Recognize the problems

The most serious globalization problem is functionality loss, either immediately (when a culture/locale is changed) or later when accessing input data (non-U.S. character input).

Some functionality problems are detectable as display problems:

• Question marks (?) appearing instead of displayed text indicate problems in Unicode-to-ANSI conversion.
• Random High ANSI characters (e.g., ¼, †, ‰, ‡, ¶) appearing instead of readable text indicate problems in ANSI code using the wrong code page.
• The appearance of boxes, vertical bars, or tildes (default glyphs) [â–¡, |, ~] indicates that the selected font cannot display some of the characters.

It might be difficult to find problems in display or print results that require shaping, layout, or script knowledge. This test is language-specific and often cannot be executed without language expertise. On the other hand, your test may be limited to code inspection. If standard text-handling mechanisms are used to form and display output text, you may consider this area safe.

Another area of potential problems is code that fails to follow local conventions as defined by the current culture/locale. Make sure your application displays culture/locale-sensitive data (e.g., numbers, dates, time, currency, and calendars) according to the current regional settings of your computer.

The Regional Options in Control Panel does not cover all culture/locale-specific functionality. For example, you cannot see the current sort order there. Thus, it is important to have a test plan covering all aspects of functionality related to culture/locale before you start your test.

 

 

Edited by Mithi25 - 05Aug2009 at 11:03pm