QA City

   QA City >> Expert Column
Dont Miss Experts

Some Curious Myths about Globalization Testing

Anuj Magazine
Anuj Magazine
Senior Manager, Citrix R&D India
Anuj Magazine is a Software Testing practitioner currently working at Citrix R&D India as Sen... more>>

In his landmark book - "The World is Flat", Thomas L Friedman has beautifully summarized the advent of World Globalization into 3 different eras -

Globalization 1.0:

Globalization 1.0 was primarily the globalization of countries that began with Vasco da Gama and Christopher Columbus started exploring the world. And that era, one could say, started in the 1400s and continued all the way - in its own way - right up to the invention of the steamship, the railroad and the telegraph, but ended with World War I. At the end of this era, the world gradually shrank from "Size Large" to "Size Medium".

Globalization 2.0:

This era was from World War II right up until year 2000, until Y2K--the era when the world continued to "shrink," when multinational companies increasingly went global for markets and labor, and when technological innovations continued to reduce transportation, communication, and production costs. Globalization 2.0 shrank the world from a "Size Medium" to a "Size Small" with the innovations in the field of telecommunication like Telegraph, Telephone, PC, Fiber Optics, and World Wide Web.

Globalization 3.0:

This period is something that really shrank the world further from "Size Small" to "Size Tiny". Globalization 3.0 is the intensification of everything that was invented in Globalization 2.0 - the bandwidths, the fiber-optics, the PCs, and the software capabilities that connected them- but intensified to such a degree that it became a difference in kind.

We currently live in Globalization 3.0 era and in order to meet and further exceed the ruthless demands of this era, the Software products have evolved and grown in complexity. In addition to the Software being enhanced in features and Technical capabilities, one of the areas that have evolved during this era is Software Globalization. As an example - Office 95 supported 27 different languages. Office 2007 supports more than four times as many languages and the list continues to grow as the worldwide market for software grows. With the world getting tinier by the day, the demand for high quality locale aware Software is high and continues to increase. The arena of Software Globalization has also seen a positive drift from <a href="">Japanization</a> to "Simship" in the past decade or so. Many new Globalization specific concepts have emerged during this era such as SBB, MUI etc. and all this has led to Software Globalization testing become a separate discipline. While Software Globalization testing is still finding its feet as a separate discipline in many organizations, more mature organizations like ours have embraced it and have reaped benefits successfully over the years. For anyone who is new to Globalization testing, the introduction to this discipline is often surrounded by pre-conceived notions and often resulting in misconceptions. This article primarily aims at uncovering a few major myths about Globalization testing. Here we go -

Myth# 1: Globalization (G11n) Testing is primarily about Testing the User Interface

The underlying Truth -

This is a myth because - to a majority of people, the translation of UI text and labels etc. are the only changes that get done when a product is globalized. There is no doubt that whenever an application gets translated to any other language, the UI changes are the most prominent in the product. All the text/labels that were originally displayed in the English language now get shown in the translated language. Though UI changes are the visibly significant changes, technically these are only a small part of the changes that get done as a part of Globalizing the Software. A few examples of activities involved in Globalizing the software include:

- Externalizing the UI.
- Design UI so that strings can expand.
- Ensuring that the product can support international character sets.
- Eliminating strings corruption.
- Ensuring that the application is locale aware.
- Support for bidirectional text.
And many more...

A typical G11n testing cycle (especially after Localization Release To Test phase) might have more UI issues logged than the actual functional issues depending upon the quality of Globalization implementation, but that doesn't mean that majority of testing efforts gets spent to find UI issues only as there is a considerable testing effort spent to verify the other aspects of Globalization as well.

Myth # 2: A person who doesn't know French cannot test the French version of the Software

The underlying Truth -

Other than the testing required for Language verification on the User Interface and the documents, every other aspect of Globalization testing can be done by a test engineer who is not well versed with the language under test. In fact, the Internationalization aspect of Globalization testing is usually done by Engineers who are not quite well versed with the language. Some facts:

1. The User Interface of localized Software products is generally consistent with the English language User Interface. A tester first gets trained on the English version of the Software product and then switches to testing on a language specific version of Software. The tester gets acquainted with the entire User Interface map in English language and thus knows what options he/she is accessing on a language specific build.

2. The language part of testing is best done by the native speakers of that language. There is a vast difference between native speakers and the person who has learnt a foreign language. It is generally very difficult to find a person who is technically a subject matter expert, an Expert in Software testing and a native language expert as well. If at all one manages to find one such person for one supported language, it may not be equally feasible to find such a person for all the supported languages. In such a scenario, the language part of Globalization testing (usually referred to as Localization testing) gets done by native language expert and the Functional part of Globalization testing (referred as Internationalization testing) is done by testing Experts.

Myth# 3: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the Globalized applications

The underlying Truth -

In almost all the Software products, the International versions have the same features and functionalities as the English version of Software. Many people new to the Globalization testing tend to believe that the test cases meant for testing English version of the product can be used for testing the International versions of the Software. This is typically not correct. Let me try to put things in perspective here:

1. It is true that for the sizable chunk of Globalization testing, the Base language (usually English) Functional test cases can be used. The prime reason of following this approach is that one of the objectives of Globalization testing is to ensure that the localized version of Software works as reliably on localized test environment as English language product does on English language test environment.

2. However, it is very costly and inefficient to run all the English language functional test cases for all the languages being supported. Suppose a Software product supports 4 languages, if one intends to run all the English language test cases for all the languages, then the overall effort would be 400% more- which is impractical. Usually, if a product is properly Internationalized- there would be a single code base catering to all the supported languages. If this is the case, there won't be much risk in executing the testing by striping the test cases across the languages, for a certain number of similar languages at least.

3. It is equally untrue that Globalization testing constitutes "just" executing the English language test cases on localized languages. Apart of executing English based test cases on the localized test setup, there is a great deal of testing that needs to be done to test the International requirements of a particular language under test e.g. If you are testing German language Software, one needs to focus on German keyboard and testing using German characters, test for German date/time format, number formats, Sorting order, printer settings and a whole list of related things. Usually one ends up testing a whole lot of additional things.

Myth# 4: If a test case works fine in French language, it will work fine in German language as well

The underlying Truth -

This one is little tricky to explain but it is definitely a myth. Here are a few points around this:

1. Lets consider a case of application being globalized for the first time. And assume that the application is going to support multiple languages. There are several factors that need to be kept in mind as the testing scope is decided-

a. First is to check if there are any changes in application binaries between the languages or all the languages use the same binary (Single base binary). If the binaries are the same across all the languages, then the next step is to know what changes have been done to the product from the Internationalization perspective across all the languages. Changes done to the product while creating builds needs to be taken into account. Based on any of these changes, the results may differ across the languages.

b. If the application is being internationalized for the first time, then the testing should be as thorough as possible as chances for mistakes are high.

2. On the other hand, applications that have been through multiple Internationalization releases i.e. already support multiple languages, are generally going to be more stable and the variations of test results across the languages would majorly depend upon the changes that has gone into the Software between previous releases and the current one. In order to perform the Risk based testing across the different languages that are supported, one thought line that is usually applied is that all the Single byte languages such as French, Spanish, and German usually tend to behave the same way and the testing can be equally distributed across all these languages. Special care is usually taken to handle the testing of multi-byte languages such as Japanese, Simplified Chinese, Traditional Chinese etc. mainly because of the different character-sets that these languages deal with.

Myth# 5: Globalization testing doesn't require the same test setup as is required to do the base language testing. Globalization testing can be done with a minimum test setup.

The underlying fact -

This statement may be typically true if we are taking about System II or System III testing setup but as far as the System I test setup is concerned (including OS, other third party software, hardware etc.) Globalization testing usually requires the same setup as System I English testing, though it will require a fully localized setup e.g. German Win 2003 server, German Exchange server, German keyboard etc.

Remember - one of the basic purposes of Globalization testing is to ensure that the International version of the application on the respective language test setup works the same as English language version would work on English test setup.

Experts on QA
Swaid Qadir Bhat
Sr System Architect
Virtusa Corporation
Subhash  Motwani
Prasad Rao Pasam
Ayaskanta  Mohanty
Managing Director
TATWA Technologies
Rajesh  Dagar
Software Architect
Connect Icon Pvt Ltd
Yasar  Khuthub
Software QA Manager
Azure IT Solutions
Sunil  Bhat
Project Management
HCL Infosystems Limi
Sharad  Agarwal
Team Lead