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.
The following must be part of your globalization-testing plan:
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
- 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:
- A combination of both (one selected for the System locale and another
for the User locale) whenever possible to cover multilanguage support
You can achieve the most complete coverage if you install all the language
groups, rotate the cultures/locales, and run "globalized" tests as described
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:
- 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).
- Set the culture/locale on the test machine to different cultures/locales
from your local culture/locale (Japanese or German).
- 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
After the environment has been set for globalization testing, you must pay
special attention to potential globalization problems when you run your regular
- 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.
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.