Saturday, June 14, 2008

Uncovering Myths about Globalization testing -1

In continuation with one of my previous posts , I am sharing some of my experiences with Globalization testing.
Software Globalization (abbreviated as G11n), simply put is a combination of 2 activities- Internationalization and Localization
Internationalization is planning and implementing products and services so that they can easily be localized for specific languages and cultures. So for any product to be successfully localized in to different languages, it is imperative that it has to be internationalized properly. Internationalization is abbreviated as I18n.
Localization is the aspect of development and testing relating to the translation of software and its presentation to the end user. Localization is abbreviated as L10n.
The extent and the quality of Internationalization and Localization are tested by means of Globalization (G11n) testing. G11n testing is a specialized field in itself and it requires specific skills and expertise to be successful at this form of testing. Because of surface level similarity this testing has with Functional testing, it is often wrongly compared leading to false conclusions. In this write-up, I intend to uncover some of the common myths around the G11n testing.

Myth 1: G11n testing is not technical enough
This is a myth because it is more based on Ignorance rather than a thoughtful observation. As G11n testing is a separate form of testing altogether, there is a lot of scope of learning new and specific technologies. Organizations which are serious about developing and selling the products for an International market usually have a separate group which takes care of the Globalization aspects of the product. A person testing internationalized version of the Software needs to be detailed in his knowledge in the following areas-
- An I18N tester needs to have to have an in-depth knowledge of features and functionalities of the application under test. He/she needs to understand the product under test as well as Functional tester does.
- An I18N tester needs to be well versed with the technical concepts of Internationalization such as Single base binary, Unicode, Multi-lingual support, different encoding systems, code-pages, Locale awareness etc. Without the knowledge of these concepts, a tester will never be able to find good I18N bugs.
- Troubleshooting the I18N related issues requires additional skills and knowledge of the Internationalization concepts.
- An I18N tester needs to have a fair bit of knowledge about the Technical architecture of the product under test. Without this knowledge, he/she will not be able to accurately assess the impact any change in software product would have from the Internationalization perspective.
- An I18N tester is usually an interface to the Translation experts. It is very likely that the Translation experts because of the nature of their job may not be technically proficient. Usually, I18N test teams help the Translation experts in their unit testing involving complex product setups.
Apart from the purely technical knowledge needed by an I18N tester, it is imperative for a person to have knowledge about the cultural considerations for different countries including (but not limited to)- understanding the date/time formats, number formats, preferred printing options, currencies etc. This makes the job of an I18N tester even more interesting and challenging.

Myth 2: G11n testing is majorly about testing the UI
This is a myth because- to the majority of people, the translation of UI text and labels etc. are the only changes that get done when a product is internationalized.
There is no doubt to the fact that whenever an application gets localized (aka translated) to any other languages, the UI changes are the most prominent in the product. All the text/labels that were originally displayed in the base language (which are usually English), now gets shown in the translated language. Though UI changes are prominent but technically these are only one of the changes that get done as a part of Globalizing the Software. A few examples of activities involved in internationalizing 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 Regional settings are read from OS.
- Support for bidirectional text.
And many more..
A typical G11n testing cycle might have more UI issues logged than the actual functional issues depending upon the quality of Globalization but that doesn’t mean that majority of testing efforts were spent to find UI issues as there is a considerable testing effort spent to verify the other aspects of Internationalization as well.

Myth 3: G11n Testing can start only after the base product is translated
This is one of the common misconceptions for the people completely unaware of Software Globalization concepts. To give a brief background, Globalization of software happens appropriately in different phases when the base product (The English language product) is being developed. In an Ideal development scenario, the software development consideration from Internationalization perspective begins alongside with base product development. So, when the feature complete build gets released for testing, it has all the Internationalization features built-in but point to note here is that the Localization of software hasn’t happened yet. Localization of the software product usually happens after the User Interface for the base product is frozen. Before UI Freeze, the Globalization test team's focus is testing the Internationalization aspect of the product. So, the testing for Globalization starts much before the translation of the Software happens.

Watch out for more such myths being uncovered in this space!

No comments: