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
file:///C:/DOCUME%7E1/Owner/LOCALS%7E1/Temp/msohtml1/01/clip_filelist.xml -
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
http://onestoptesting.com/globalization-testing/plan.asp# -
- 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,
http://onestoptesting.com/globalization-testing/plan.asp# -
-
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:
- 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
http://onestoptesting.com/globalization-testing/test-environment.asp# -
-
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
http://onestoptesting.com/globalization-testing/execute-tests.asp# -
-
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
http://onestoptesting.com/globalization-testing/execute-tests.asp# -
- 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.
------------- http://www.quick2sms.com - Send Unlimited FREE SMS to Any Mobile Anywhere in INDIA,
Click Here
|