I18n/L10n test guide line

Here are some guide lines or strategies for globalization testing,
sorry but you have to scroll down to see the table for unknow reasons:

Category	I18n functional testing	Pseudo l10n testing	L10n message testing	L10n functional testing
What to test	Installation and uninstallation of l10n support in CLI/GUI/Silent modes, all functions especially input, output (fonts, display and printing) and internal conversion or processing of non ASCII characters in non English environment.	Hardcoded messages hardcoded button/menu/label width, garbages, white boxes, question marks, mismatched encodings or bad layouts in CLI/GUI installation, CLI commands, BUI, Error messages, OLH, etc.	Correct and consistent translations of all of the messages.	All of the Locale data, all of the input methods, the fonts, display, and printing in all applications, all of the converters, etc.
Who to write test cases	I18n developers, base team or i18n SQEs (Software Quality Engineers)	I18n developers, base SQEs	I18n developers, base SQEs	L10n developers, l10n SQEs
Who to do the testing	I18n developers, base team or i18n SQAs (Software Quality Asurances)	I18n developers, base SQEs, l10n SQEs, l10n Ces, l10n tech leads, etc	L10n SQAs	10n developers, l10n SQAs
Where to test	In one Asian multiple byte locale of each OS release on all platforms	In one locale of one OS release On all platforms	One language in one release on one platform	all releases on all platforms
When to test	When the features are implemented or bugs are fixed, before l10n message engineering is started	During development, while messages are being translated, before l10n testing is started	After the message translations are integrated	When the features are implemented or bugs are fixed
How often to test	Whenever there are new features or bug fixes	Whenever there are message updates	Rotate sub test groups among builds	Whenever there are new features or bug fixes

Posted at 01:40PM Oct 19, 2006 by byuan in Globalization  |  Comments[0]