Testing Process for Globalization

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.

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 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.

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.

• 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.

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.