I attended Hadoop India User Group meet today at Impetus, Noida. It was great to listen to speakers from Impetus, IBM and Yahoo. The event was attended by many enthusiastic engineers and they were leaving no chance to query the speakers and wanted to go into minute details of the topics that were being presented. I will like to congratulate my friend and coworker Sanjay Sharma for successfully organising this event.

Impetus Technologies has launched its much awaited test automation framework called iLeap. iLeap boasts of reducing the automation test suite development efforts by upto 40% and maintenance efforts by upto 60%. Read more at

http://www.free-press-release.com/news/print-1253707928.html

Please feel free to post your comments or suggestion related to iLeap.

Within a product, there are various functional areas that can be termed as more critical as compared to others. Such functional areas require special attention during testing so that critical bugs do not leak away to the production. It has been noticed that people often make mistake in identifying the correct critical functional areas of a product for a particular release. It is majorly because identifying critical areas is done on gut feeling and there is no scientific or mathematical approach that is available to do so.

qLabs is coming up with a webinar on Feb 20th, 2009 @ 10:00 am PT/ 1:00 pm ET on their new scientific approach that they have developed to identify critical functional areas within a product.

So if you want to get benefitted with this and want to try this absolutely free, register for this webinar using link http://www.impetus.com/impetusweb/retrieveEvents.jsp?id=8&event=upcoming

Register to join qLabs-Test Automation webinar http://www.impetus.com/webinars.html on 14th November.

About qLabs
Impetus Technologies’ Test Engineering Group, qLabs, focuses on software test engineering. We have gained strong technical expertise through constant innovation and research on the technology, tools available, and methodologies related to software testing. We have proven abilities in building test automation using various industry standard and Open Source Tools. Our engineering approach to test engineering in general and test automation in particular results in higher productivity and improved test effectiveness while lowering maintenance cost and the overall cost of the ownership.

Objective

In today’s world, most of the companies are aiming to go global in order to tap the vast opportunities that exist in various global territories. To achieve this aim, there is a growing need of their applications (web and desktop) and websites to support multiple languages. Apart from developing such applications, there is a huge demand for testing these applications.

During my career, we did a lot of research for performing effective language specific testing for various applications. In this paper I am summarizing the findings which can help any novice to understand and achieve effective internationalization testing.

What is Internationalization

Internationalization (abbreviated as “i18n”) entails to design and development of an application or product that removes the barriers to localization.

It can be termed as a process or a practice that allows easy migration of a product from one language to another. The main aim of internationalization is that it helps in product localization.

What is Localization

Localization (abbreviated as “l10n”) entails to adaptation of an application or a product to support the language, culture and other requirements of a particular Locale.

The first thing that comes to anyone’s mind when asked to perform localization is translation to a particular language. But localization is not just translation. During the course of this document you will come to know about the various things that will help you to perform effective localization testing.

Environment Compatibility

Though Unicode is becoming an increasingly adapted standard for coding, still different Operating Systems show different behaviors for this support. Windows 2000 and Windows XP provide a support for i18n, but Windows Millennium shows a bit of issues with Unicode. Other kind of issues can be seen with Mac and Unix platforms.

Know the Languages and Locales

Various different languages in the world have different characteristics. To build an application that is compatible with Western Europe languages is simpler to the one that needs to support Far eastern languages like Arabic.

For Left-to-Right (L2R) languages, some of these languages require more screen area as compared to English. E.g. German language UI typically require almost 30% more area than that required by English. Some text translations can also raise issues like in Spanish, OK is translated to ‘Aceptar’, which will raise the issue of button size.

For Right-toLeft (R2L) languages, to perform tests for these languages, an input Method Editor (IME) is mostly preferred as they require a combination of keys for the 101 key keyboards. Among other far east languages, Japanese language uses the combination of two syllabaries with ideographs and also makes use of Latin characters as well, which further complicates the testing process.

Before starting testing identify and decide on the locales that are to be certified initially.

Identify Areas to Test and create Test Plan

It is very important to define the environments before starting the testing for internationalization. The hardware and software requirements for an application that needs to be internationalized should be narrowed down, in the starting, for getting quick results.

Apart from locale language, some of the things that should be kept in mind while testing for localization are

• Date and time formats – Some regions put date in dd/mm/yyyy while some put the same in mm/dd/yyyy. The clock is preferred in some regions as in 24 hour format, while some prefer AM/PM.
• Numeric – These can be denoted differently in different countries. Like in US, 100000 is written as 100,000 while the same in India is written as 1,00,000.
• Use of currency – Currency is different for different locales. Even in English locale, currency is different for different countries like US and Canada.
• Symbols, icons and colors – Color schemas can be different for different regions. Like in the traffic lights in US, “Green” symbolizes the “Go” while in Japan the color for same is “Blue”. Same holds true for symbols and icons for regions.
• Names – Most of the English speaking countries use First Name + Middle Name + Last Name, but in some countries like China, Family Name is considered as the First Name. Similar kind of differences can be seen for different countries.
• Keyboard Usage – Apart from the 101 Key Keyboards, different countries have different key caps. Like English-language keyboard starts with “qwerty”, while a German-language keyboard starts with “qwertz”.
• Text and graphics can contain references to objects, actions or ideas which make different sense in different regions
• Varying legal requirements including the appropriate contact information for various locales

Based on the above information, create a Test Matrix that includes platforms and versions for all the components eligible for certification. Create test cases based on the following guidelines:

• Specify tests for English and non-English configurations.
• Develop non-ASCII data for any text that is used in testing. This can either be real non-English data or it can be pseudo-localized data.
• Develop tests that use non-ASCII values in path names, file names, URIs, account preferences, etc., not just in “regular” data.
• Develop tests for time or date values that specify different time zones and include cross-time zone and daylight savings.
• Create some testcases for some mixed configurations (such as Indian client to Japanese server).
• Develop tests for localizability
• Test the Life-cycle (install, uninstall, configure, etc.)