Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Globalization Testing for Application Blocks

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

patterns & practices Developer Center

Microsoft Corporation

January 2005

Summary: Covers globalization test planning, scenarios, and environment setups with a sample test scenario.

Contents

Objective

Overview

Testing Process for Globalization

Summary

Additional Resources

Objective

  • Learn the process of globalization testing.

Overview

Globalization is the process of internationalizing the application code so that it supports multiple locales and cultures. The process of internationalization ensures that the application is able to process content, referred to in this chapter as universal data, for any locale with little or no change to the code base. Locale is a combination of both language and cultural environment, including information such as the format of dates, times, currencies, character classification, and sorting rules for strings. Therefore, a goal of internationalization is to separate the locale-dependent content from locale-independent content. Another goal is to use code that is able to process the locale-dependent content. This ensures that the application can be easily localized for a particular culture or locale.

Globalization testing ensures that the code is able to handle the local content for the targeted locales without any data loss or inconsistency. It also ensures that the application block can be integrated with world-ready applications. A world-ready application mostly targets a limited number of locales; however, the goal for an application block may be to support integration with an application that targets any locale or culture. The scope of testing can be limited to testing with a few cultures from different regions to ensure that the application block is able to support content from diverse cultures.

The Configuration Management Application Block (CMAB) is used to illustrate concepts in this chapter.. The requirements for the CMAB are as follows:

  • It provides the functionality to read and store configuration information transparently in a persistent storage medium. The storage media are Microsoft® SQL Server™, the registry, and an XML file.
  • It provides a configurable option to store the information in encrypted form and plain text by using XML notation.
  • It can be used with desktop applications and Web applications that are deployed in a Web farm.
  • It caches configuration information in memory to reduce cross-process communication such as reading from any persistent medium. This caching reduces the response time of the request for any configuration information. The expiration and scavenging mechanism for the data that is cached in memory is similar to the cron algorithm in UNIX.
  • It can store and return data from various locales and cultures without any loss of data integrity.

Testing Process for Globalization

The following process formalizes the set of activities that are required to ensure a world-ready application block. The process can be easily customized to suit specific needs for an application block by creating test plans that are specific to particular scenarios.

Input

The following input is required for the globalization testing process:

  • Functional specifications of the application block
  • Requirements for the application block
  • Deployment scenarios for the application

Steps

The process for globalization testing is shown in Figure 7.1.

Ff649500.f07mtf01(en-us,PandP.10).gif

Figure 7.1. The testing process for application blocks

The globalization testing process consists of the following steps:

  1. Create test plans. Create test plans based on the priority of each scenario and the test platforms it needs to be tested on.
  2. Create the test environment. Set up the test environment for multiple locales that are targeted for the application block.
  3. Execute the test cases. Execute the test cases in the test environment.
  4. Analyze the results. Analyze the results to ensure that there is no data loss or inconsistency in the output.

The next sections describe each of these steps.

Step 1: Create Test Plans

You must create test plans for the application block scenarios that you must test for globalization. In general, you can develop the test cases (detailed test plan document) and the execution details for each test case (detailed test case document) based on the functional specifications and the requirements document. The functional specification document describes the various interfaces that the application block will expose. The requirements document specifies whether the application block is targeted toward a specific set of locales or whether it is just required to be globalization-compliant.

When you create the test plans, you should:

  • Decide the priority of each scenario.
  • Select the test platform.

The next sections describe each of these considerations.

Decide the Priority of Each Scenario

To make globalization testing more effective, it is a good idea to assign a priority to each scenario that must be tested. You should check for the following to identify the high priority scenarios:

  • Check if the application block needs to support text data in ANSI format.
  • Check if the application block extensively processes strings by performing tasks such as sorting, comparison, concatenation, and transformation (conversion to lowercase or uppercase).
  • Check if there are certain APIs that can accept locale-specific information such as address, currency, dates, and numerals.
  • Use files for data storage or data exchange (for example, Microsoft Windows metafiles, security configuration tools, and Web-based tools).

In the case of the CMAB, the primary usage functionality is to store and retrieve configuration information from various data stores. Some of the globalization-related testing should test the following high priority scenarios in the CMAB to make sure that the data is stored and retrieved without any loss of integrity and consistency:

  • The CMAB is able to store locale-specific information such as currency, dates, and strings in the supported data stores without any loss of data integrity.
  • CMAB is able to return the locale-specific information in its original form if the locale of the user requesting the information is the same as the locale of the stored data. There may be a requirement that if users from diverse locales are accessing the information, the information should be converted to the user's locale before it is returned. This requires development of custom handlers that can deserialize the data to meet such a requirement for a particular scenario. However, the globalization testing needs to ensure that such customization is possible with the application block.

    Consider the scenario where the CMAB is integrated with an online chat application that can be accessed from different time zones. The Web server and the application clients fall under different time zones in such a way that the local time at the server and the local time at the client are different. During testing, you should ensure that the custom handlers convert the local time (local data) from the user into universal time (universal data) before storing it as configuration values. In this way, each user sees what time other users logged in according to his or her local time zone.

    The following code snippet illustrates this scenario.

    //Converts the local time to universal time before storing it for UserA
    System.DateTime univDateTime = localDateTime.ToUniversalTime();
    //Stores the universal date to the default configuration section
    ConfigurationManager.Items("universalTime") = univDateTime.ToString("G", DateTimeFormatInfo.InvariantInfo); 
    //The universal time is retrieved and converted to a value according to the //time for the user making the request
      

    The stored configuration values can be accessed using the CMAB and displayed in the local time, as and when required. If a user from a different time zone requests the same configuration information, the value can be converted to his or her time zone.

  • Assuming that the CMAB provides out-of-the-box support for a fixed number of locales by providing satellite assemblies for resources, you should test all scenarios that result in an exception. Testing these scenarios ensures that the exception messages from the CMAB are on expected lines without any truncation or deformation (loss of characters or the introduction of junk characters) of the actual string.

Select a Test Platform

Identify the operating system that testing is to be performed on. If the requirements explicitly state that the application block needs to support a specific set of cultures, you have the following options for choosing a test platform:

  • Use the local build of the operating system. You can use the local build of the operating system, such as the U.S. build, and install different language groups. The application that is used to test the application block can then change the current UI culture and test that the exception messages and other data returned by the application block are in accordance with the current UI culture.
  • Use the Multilanguage User Interface (MUI) operating system. The user can change the language that the UI of the operating system will be displayed in and test the application integrating the application block. The application block should also be able to return the error messages and other data based on the current culture settings. This approach is easier than installing multiple localized versions of the operating system.
  • Use the localized build of the target operating system. This approach does not have a significant advantage over the preceding options.

If you do not have an explicit requirement for the locales that must be supported by the application block, you can test by installing a minimum of two language groups from diverse regions, such as Japanese and German. This ensures that the application block is able to support locales from diverse cultures.

Sample Test Scenario

Consider an auction site that uses the CMAB to store and retrieve the prices that are quoted by various users. Suppose UserA (from Germany) quotes a price of €1,500 (euro) for his tennis kit through the auction site. UserB (from England) logs on to the auction site and views UserA's offer.

The price displayed to UserB should be £1,000 (British pounds). This is the equivalent of €1,500.

The following code illustrates the session for UserA.

//Configures the server language as U.S.-English for storage purposes
ConfigurationManager.Items("serverLanguage") = "en-US"; 
//Configures the language preference of the client as German
ConfigurationManager.Items("localLanguage") = "de-DE"; 

//Sets the culture/locale of the current thread to German
Thread.CurrentThread.CurrentCulture = new CultureInfo (ConfigurationManager.Items ("localLanguage")); 

//Stores price quoted by UserA in euro
Double dblLocalPrice = Double.Parse(txtPrice.text, NumberStyles.Currency); 

//Convert Currency Value
//User-defined function to convert currency value from euro (XEU) 
//to U.S. dollars (USD)
Double dblServerPrice = convCurrency (dblLocalPrice); 
Thread.CurrentThread.CurrentCulture = new CultureInfo (ConfigurationManager.Items ("serverLanguage"));
//Sets the culture/locale of the current thread to server's local language
//Storing the price in server through CMAB
ConfigurationManager.Items ("price") = dblServerPrice.ToString ("c");
  

The following code illustrates the session for UserB.

//Configures the language preference of the client as U.K. English
ConfigurationManager.Items ("localLanguage") = "en-GB"; 

//Retrieves the price in server through the CMAB
Double dblServerPrice = Double.Parse (ConfigurationManager.Items ("price"), NumberStyles.Currency); 

//User-defined function to convert currency value from U.S. dollars (USD)
//to British pounds (GBP)
Double dblLocalPrice = convCurrency (dblServerPrice); 
//Sets the culture/locale of the current thread to U.K. English
Thread.CurrentThread.CurrentCulture = new CultureInfo(ConfigurationManager.Items("localLanguage")); 

//Displays the converted currency in U.K. English format
lblPrice.Text = dblLocalPrice.ToString("c"); 
  

Step 2: Create the Test Environment

As mentioned earlier, to perform globalization testing, you must install multiple language groups on the test computers. After you install the language groups,, make sure that the culture or locale is not your local culture or locale.

You should make sure that the locale of the server that the test harness for the application block is hosted on is not the same locale as that of the test computers.

For the culture or locale example (the second test scenario in Step 1), configure the following:

  • Server. Install U.S.-English language and time zone support.
  • UserA's system. Install German language and time zone support.
  • UserB's system. Install U.K. English and time zone support.

Step 3: Execute Tests

After the environment is set for globalization testing, you should focus on potential globalization problems when you run your functional and integration test cases. Consider the following guidelines for the test cases to be executed:

  • Put greater emphasis on test cases that deal with passing parameters to the application block. For the sample scenario considered earlier, you can consider test cases that determine the correct selection of the culture or locale in accordance with the user's location and choice of environment. It focuses on the following code for the preceding example.
    //Sets the culture/locale of the current thread to German
    Thread.CurrentThread.CurrentCulture = new CultureInfo(ConfigurationManager.Items("localLanguage")); 
    //Stores price quoted by UserA, in euros
    Double dblLocalPrice = Double.Parse (txtPrice.text); 
      
  • Focus on test cases that deal with the input and output of strings, directly or indirectly.
  • During testing, you should use test data that contains mixed characters from various languages and different time zones.

You can create automated test cases by using a test framework such as NUnit. The test stubs can focus on passing various types of input to the application block API. In this way, you automate the execution of test cases and ensure that each new build of the application block during the development cycle is world-ready.

Step 4: Analyze the Results

The tests may reveal that the functionality of the application block is not working as intended for different locales. In the worst-case scenario, the functionality may fail completely, but in most of the scenarios, you may have issues similar to the following:

  • Random appearance of special characters, such as question marks, ANSI characters, vertical bars, boxes, and tildes
  • Incorrect formatting of data, such as date and currency, in the return values from the application block
  • Error message text that does not appear in accordance with the current locale setting

Each of these issues has a different root cause. For example, the appearance of boxes or vertical bars indicates that the selected font cannot display some of the characters; the appearance of question marks indicates problems with Unicode-to-ANSI conversion.

For a complete list of globalization-related issues, see "Globalization and Localization Issues" on MSDN at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconGlobalizationLocalization.asp.

Usually, a simple code review of the module reveals mistakes such as hard-coded strings, misuse of an overloaded API that takes the culture or locale related inputs, or an incorrectly set culture-related property for the thread that the call is being executed in. There may be other scenarios where the code converts strings from lowercase to uppercase before performing a case-insensitive comparison. This may produce unexpected results for certain languages, such as Chinese and Japanese, that do not have the concept of uppercase and lowercase characters.

Summary

This chapter explained the process for globalization testing of application blocks. It is important to note that you can significantly reduce rework due to globalization testing by performing a thorough code review to make sure that the code complies with all globalization-related best practices. In most scenarios, the testing effort can be focused around a specific set of issues that affect applications in general. For a complete list of globalization-related issues, see "Globalization and Localization Issues" on MSDN at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconGlobalizationLocalization.asp.

Additional Resources

For more information, see the following resources:

Start | Previous | Next

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.