Skip to main content

Globalization Step-by-Step

Sample International Test Cases

Summary Globalization Step-by-Step Introduction
*

On This Page

Test Cases for Deployment and General FunctionalityTest Cases for Deployment and General Functionality

Test Cases for Text HandlingTest Cases for Text Handling

Test Cases for Locale AwarenessTest Cases for Locale Awareness

Test Cases for LocalizabilityTest Cases for Localizability

The following list is provided as a possible foundation for internationalization of test plans. The test items are broken up into basic areas of functionality and are accompanied by details on how these areas can be verified, what the potential problems associated with certain areas are, and when the test is applicable.

The checklist shown in the following tables cannot possibly cover every situation that might arise; nor can it address all the numerous areas of functionality within individual applications. However, it does offer valuable guidelines for some of the more common areas of functionality that you should test.

Top of pageTop of page

Test Cases for Deployment and General Functionality

Areas and Items to TestDetailsApplicability
Application setup under different language environments

Install on a platform where the UI language of the operating system does not match the language of the application; verify with different UI languages, system locales, and user locales that do not match.

Verify the ability of the application to work with localized operating-system objects. European-language versions of Windows might be the best choice of a platform because they are deeply localized.

If the application implements an MUI behavior, make sure its UI language follows the UI language of the operating system.

All applications; if the application implements MUI functionality, make sure the default UI language of the application follows the UI language of the operating system.
Application setup on an operating system with MUI installed and where user's default UI language is different from EnglishVerify the behavior in a multilingual environment where the UI language is defined by rules different from those of the older systems. Change the system and user locales to verify multi- lingual abilities of the UI.All applications; applications that implement MUI behavior must undergo testing that is even more extensive.
General functionality with various system and user-locale settingsVerify that the code does not have unwanted locale dependencies.All applications
Uninstalling the application with different locale settingsMake sure that system-locale and user-locale settings that were active when the application was installed are different from those set at the time when the application is uninstalled.All applications
Multiplatform installation

Applications that need to be installable on multiple platforms should call code page-based code for installation on downlevel plat- forms (Windows 95 and Windows 98).

Make sure the UI that is displayed is not compromised on platforms with nondefault language settings. Unicode-based applications must work properly with different system-locale settings. No change in the user-locale settings or the user's UI language preferences should cause functionality or display problems.

Applications that target downlevel platforms or communicate with legacy systems

 

Top of pageTop of page

Test Cases for Text Handling

Areas and Items to TestDetailsApplicability
Interactive text input using different input locales

Enter text while switching between different keyboard layouts and Input Method Editors (IMEs).

Verify the ability of the application to accept input from various input methods, regardless of other locale settings.

Either check that multilingual input is enabled with all supported input methods or that it is blocked for all languages except supported ones.

Applications that allow for interactive text input
Clipboard operations with multilingual text

Verify that multilingual text can be copied to and from the clipboard.

Make sure the use of the clipboard (while cutting and pasting) does not compromise the limitations placed on localized text. Examples of such limitations might be those imposed on applica- tions interacting with non- multilingual components or systems, or when the text being passed on must match the system locale.

Applications that allow clipboard operations
Device-independent multilingual outputAll methods of output-such as displaying UI text, printing, storing in an enhanced metafile (EMF)-must preserve the multilingual features of the text. These methods should not introduce problems due to different text encoding, font, or settings used for other output methods.Applications that perform text output
Font independence

Verify that the names of fonts the application uses are not hard-coded.

Run the application on a localized operating system where font names are localized and where default shell fonts are different from those used in the English operating system. (Localized Japanese Windows is a good example.) Change the default font settings of the applications.

Applications that have text in the UI
Text handling in the UI

Check that multilingual text can be edited, entered, and deleted. Verify that word wrapping breaks text prop- erly, regardless of the lan- guage. Make sure characters can be changed to uppercase and lowercase according to the settings of the language and the locale.

Verify alignment of the multilingual output.

All applications that perform special text formatting; applications that use cus- tom solutions, rather than standard Windows controls, for text editing.
Cursor movement and positioningVerify that the cursor can be positioned correctly at the start and end of characters and text. Check cursor movement and text selection. Pay greater attention to wide ideographic characters (such as kanji characters) and bidirectional (BiDi) text, since these can cause cursor movement problems if not handled properly.Applications that don't use standard Windows controls for text editing
Handling of character encoding-double byte character set (DBCS)Set an East Asian system locale; use text encoded with single-byte and double-byte values in the selected code page. Incorporate into the test data characters that might be "risky" for your application. (For information on detecting characters that could be risky, see Appendix N, "Risky Characters.")Applications that implement non-Unicode text handling
Handling of OEM and Windows encodingsSet the system locale where some character code-point values defined by Windows and OEM code pages are different. For example, the code-point value of "small sharp s" (ß) is 0xE1 in code page 850, set with the German system locale. However, Windows code page 1252, which is associated with this same German system locale, defines this letter as 0xDF. Use characters such as ß in the test data, and verify that they are never displayed, stored, or retrieved as some other character.Applications that implement non-Unicode text handling; network and console applications
Handling of complex scriptsMultilingual applications must process complex scripts correctly-either by using standard Windows controls or calling special complex-script handling routines like those of Uniscribe. Check that BiDi text is properly reordered, that Arabic text is correctly shaped, and that word-breaking rules are applied to Thai text.Applications that implement custom complex-script handling; basic verification is required for all applications sold in markets where com- plex scripts are used.
Handling buffer sizes for multibyte character set (MBCS) textMake sure that text conversions between encodings that use different numbers of bytes per character do not cause buffer overflows, memory leaks, or text truncations. Storage of the same text encoded in UTF-16, UTF-8, and UTF-32, might require buffers of different sizes.Applications that handle different text encodings
Language-independent data persistenceApplications must store and retrieve documents containing multilingual data, regardless of the language settings of the system where the operation is performed.All applications that store data in an external persistent storage

 

Top of pageTop of page

Test Cases for Locale Awareness

Areas and Items to TestDetailsApplicability
Locale-independent data persistenceApplications must store and retrieve documents containing locale-sensitive data (such as the date, time, and numeric information); check that this data is stored in a locale-neutral form. It must be formatted for display purposes only and must follow the rules of the settings on the reviewer's system.All applications that store data in an external persistent storage
Adherence to locale standards

Verify that locale-specific data (such as the time, date, currency, and numeric values) can be entered, interpreted, stored, and retrieved according to the rules set by the user locale.

Specifically, verify that:

  • A.M./P.M. symbols are not hard-coded for the time values.
  • Different time and date formats can be used, including different separators.
  • Dates in different calendars can be entered and edited.
  • Positive and negative number formats are recognized correctly.
  • Neither the dollar sign nor any other symbol is hard-coded as a currency symbol.
All applications
Dynamic usage of format separatorsVerify that date, time, and numeric values are entered with data separators; make sure the separators are not hard-coded in the application, but rather are defined based on the current user-locale settings.Applications that allow you to enter formatted data
Paper and envelope sizesIn accordance with the selected locale setting, check that applications pick the appropriate default paper and envelope sizes for correctly formatting information that's going to be printed. However, be sure to let the user override those settings. Verify that applications relay information about the proper default paper size to the printing device.Applications that format printable information
Measurement-systems independenceVerify that applications that use real physical dimensions for formatting graphic and text data utilize the measurement system (metric or U.S. Customary System) corresponding to the user's locale settings.Applications that use real physical dimensions for formatting graphic and text data

 

Top of pageTop of page

Test Cases for Localizability

Areas and Items to TestDetailsApplicability
Isolation of the localizable resources

Make sure all UI elements are isolated in the localizable resources. Pseudo-localization should not leave any unlocalized text in the UI. Text that remains untranslated after pseudo-localization most likely is hard-coded in the application's code and creates a localizability problem. In addition to the text that appears in the graphical user interface (GUI), verify that the following text is localizable:

  • Parts of the command-line interface
  • Messages in the Event Log and Error Log
  • Error messages
  • Tool tips
Applications that use text from external resources
Locale-independent handling of resourcesCheck that static UI text (such as names of dialog boxes, Field labels, tabs, and other things the user cannot change) is displayed in the language of the application's UI. There should be no question marks, default glyphs, or random characters in the UI, regardless of the locale or language settings of the system.Applications that use separ- ate resource modules for UI text storage
Handling of string dependenciesApplications should not rely on consistency of the resource text in different parts of the system. If the functionality of an application relies on several strings being identical in different parts of the application, either those strings have to originate from a single source, or their relationship should be clearly commented for future localization and support. Make sure that random pseudo-localization does not affect the functionality of the application.Applications that display UI text from external resources
Language-independence of the file namesNames of external files (such as Help files, satellite DLLs, and database files) that the application uses should not be localized; pseudo-localization should not change them. If pseudo-localization were to change these names, applications wouldn't be able to find their databases.Applications that open external files to perform some of their operations
Isolation of font propertiesFont properties must not be in localizable resources. Applications violating this rule are likely to use an incorrect font face and size if pseudo-localized.Applications that display text in the GUI
Font-size and display-resolution independenceVerify that applications are not affected if the size of the shell font or screen resolution is changed.Windowed applications
Localization-independent functionality

Make sure pseudo-localization doesn't affect the following areas:

  • Hot keys
  • Accelerators
  • Menus
  • Responses (like [Y|N]) required by command-line applications
  • Other UI control elements

All of the areas just listed must be accessible on a localized platform, with the input locale matching the UI language of the application.

Applications that have con- trol elements in the UI
UI adjustable to the UI text growthGrowth of the UI text length due to pseudo-localization should not cause text clipping; compensate for this problem by having the UI adjusted manually (by localizers) or automatically (with pseudo-localization). Applications should not assume the UI dimensions are fixed.Windowed applications that display text in the GUI
Mirroring-awareness in UI composition

Dynamic placement of UI elements might cause the following mirroring problems, seen after pseudo-mirroring is applied:

  • Misplaced controls in dialog boxes
  • Broken check-box display
  • Empty property pages displayed in property sheets
  • Incorrect text alignment
  • Mirroring of the text (text displayed in reverse order)
  • Display not matching the real location of the control (controls are drawn in one place but actually work in another)
Windowed applications
Localizability of nontextual resourcesFor all nontextual resources (such as images and sounds) that must be localized, make sure clear rules and requirements are defined for the localization.Applications that incorporate localizable nontextual resources
Run-time string compositionVerify that the dynamic-string composition can hold if the order of parts of the output must be changed. Make sure the composition rules are not based on a single language.Applications that build strings from pieces at run time
Dynamic retrieval of system-defined namesThe applications should not refer to built-in objects of the operating system by names stored in the application: the names of built-in accounts like "Administrator" or folders like "Program Files" must be retrieved dynamically. To check this, pseudo-localize the application and run it on a local- ized platform.All applications

 

Summary Globalization Step-by-Step Introduction
Top of pageTop of page Previous9 of 9