Uncovering Myths about Globalization testing-3

Continuing from my previous post , here are a few more myths about Globalization testing uncovered.

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

This one is little tricky to explain but it is definitely a myth. Some thoughts around this-
1. Lets consider a case of application being Internationalized 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 before defining the testing scope-
a. Check with the developer if there are any changes in application binaries between the languages. If the developer confirms the binaries are the same across all the languages, then get the information about what changes have been done to the product from the Internationalization perspective across all the languages. Also, consider the changes that have been done to the product while building the product or creating the executables. If the product is using the same binaries across all the languages AND there are no changes to the product from the Internationalization perspective AND there are no changes done to build the product AND there are no other changes in the application between languages, then one may confidently say that "If a test case works fine in one language, it will work fine in other language as well. "
In practical scenario, the answer to different if’s in previous sentence are usually not known or is not known to an extent to help you make a right decision. In such a case, to assume that a test case will behave the same way across all the languages may turn out to me quite risky.
b. Continuing with the previous point, another important point is the skill of a developer performing the Internationalization changes to the product. Designing and developing a product from I18N perspective is a specialized skill. More often you will see that the developer who does core application development may not be fully well versed with I18N concepts. If this is the case, as a tester one should better take special care when deciding to omit any test case.
c. If the application is 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, for the 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.
3. 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, German usually tend to behave the same way and the testing can be equally distributed across all these languages.
A special care must be taken to handle the testing of multi-byte languages such as Japanese, Simplified Chinese, Traditional Chinese etc. majorly because of the different character-sets that these languages deal with.

Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.

Soft keys are the "Soft" key boards layout in different languages that are provided by Windows Operating System. It can be accessed from the following locations-
- Start Menu/Programs/Accessories/Accessibility/On Screen Keyboards
- Start Menu/Programs/Accessories/System tools/Character Maps

Soft keys basically helps one enter the Foreign text without the need of an external keyboard. For majority of the testing with Foreign text, the use of Soft keys should suffice but there are a few situations that i can think of which requires one to use actual hardware-
- For some languages there are a multiple types of Keyboards (with different makes and models) available in the market. The customers of respective locales can use any of those keyboards. In such a scenarios, it is worthwhile checking at the earlier phases on what models of Keyboards are supported by the application under test and use the same for testing purposes.
- In my testing experience with Internationalized applications, i have not come across a situation where i would have found a bug in which a test scenario worked fine on Soft keyboard but not on physical keyboard but reading about other's experience here's what i found after reading the book- "Galileo Computing- Software Testing and Internationalization"
As the book states- I have seen a program in the past where foreign data was able to be entered correctly using an English keyboard on Portuguese system, so the product was shipped. However, when the program was installed by people in Brazil, who were using a Portuguese keyboard, they were not able to enter the C Celidda character(ҁ).

Though i dont know the exact reason for the above experience mentioned in the book, but this experience is a good enough indicator to not treat the tests related to entering foreign text lightly and to use the physical keyboard for different languages for testing International versions of the Software.
Always, remember- do not take chances with features related to handling the foreign text within the program. Always test it thoroughly.

Myth 10: 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.

This myth came up as a result of one of the discussions i was having with Development manager of one group. This is a myth because Globalization testing too can be as setup intensive as the base language testing can be.
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. By test setup here, i mean the Operating System, Third party products, any specific hardware etc.
One cannot possibly carry out all the necessary tests if the test setup of Internationalized applications is not same as the base language test setup.