Sample International Test Cases
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.
| Globalization: Deployment and General Functionality | ||
| Areas and Items to Test | Details | Applicability |
| 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 English | Verify 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 settings | Verify that the code does not have unwanted locale dependencies. | All applications |
| Uninstalling the application with different locale settings | Make 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 |
| Globalization: Text Handling | ||
| Areas and Items to Test | Details | Applicability |
| 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 output | All 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 positioning | Verify 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 encodings | Set 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 scripts | Multilingual 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) text | Make 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 persistence | Applications 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 |
| Globalization: Locale Awareness | ||
| Areas and Items to Test | Details | Applicability |
| Locale-independent data persistence | Applications 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:
| All applications |
| Dynamic usage of format separators | Verify 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 sizes | In 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 independence | Verify 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 |
| Localizability | ||
| Areas and Items to Test | Details | Applicability |
| 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:
| Applications that use text from external resources |
| Locale-independent handling of resources | Check 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 dependencies | Applications 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 names | Names 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 properties | Font 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 independence | Verify 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:
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 growth | Growth 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:
| Windowed applications |
| Localizability of nontextual resources | For 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 composition | Verify 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 names | The 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 |
EAN: 2147483647
Pages: 198