Uncovering Myths about Globalization testing -2

This post is a continuation of my previous post on the same topic and is based on the real time myths about Globalization testing as i have experienced.

Myth 4: A person who doesn't know French cannot test the French version of the Software
The fact here is that except for the testing required to do the Language verification on the User Interface and the documents, every other aspect of Globalization testing can be done by a tester who is not well versed with the language under test. In my experience, I have seen most of the Internationalization testing being done by people who are not language experts. There are a few points that come to my mind regarding this fact-
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. This way the tester is acquainted of the entire User Interface map in English language and thus knows what options is he/she clicking on a language specific build. It’s probably same as using English language say Windows XP as against German language Windows XP. The entire look and feel is the same, so a person who doesn’t know the target language still knows what actions he/she is doing.
2. The language part of testing is best done by the native speakers of that language. There is a difference between native speakers and the person who has learnt a foreign language with his/her's native language being something else. It is generally very difficult to find a person who is technically sound, 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) is the responsibility of native language expert and the Functional part of Globalization testing (referred as Internationalization testing) is done by testing Experts.
3. Having said this much, it must be understood that there will still be some situations in which a person unaware of language and testing the same may get struck especially while troubleshooting things or upon coming up with some sort of error message that requires translation. In such a scenario, the help of language experts or sometimes the freely available text translation tools is required.


Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
International versions of a Software program in majority of cases have the same features and functionalities as the English version of Software. This may not be true if there is a specific feature request for a particular locale. In my experience, I have not generally come across any such instance. Going by this thought, many people new to the Globalization testing tend to believe that the test cases same as English language can be used for testing the International versions of the Software. This is not typically 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 are 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. In a usual resource crunch scenario in Software releases, spending this much effort is impractical and often not required. And if at all this much effort is spent, then the Simship is not possible ("Simship" is releasing all the supported languages for a software product on the same date). In order to deal with such a situation, the English test cases are usually striped across languages meaning- running 25% of test cases on say French language, 25% each on say German, Spanish and Italian). The word of caution before agreeing to go for such an approach is basically understanding the code changes that have happened across different languages. Usually, if the 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 basing the testing by dividing the test cases across the languages.
3. However, 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 cultural requirements/International requirements of a particular language under test e.g. If you are testing an German language Software, one needs to focus on German keyboard and testing using German text, test for German date/time format, number formats, Sorting order, printer settings and a list of related things. Usually one ends up testing whole lot of additional things.

Myth 6: There is no scope of exploratory testing while testing internationalized applications
This myth has it's root in the previous myth- A tester only needs to follow the test cases executed for Base language in order to thoroughly test the Internationalized applications
There are quite a few challenges associated with the Globalization testing. Let me summarize a few of these-

1. The localized version of Software works as reliably on localized test environment as English language product does on English language test environment.
2. One of the major activities for Globalization testing is to ensure that the testing touches entire User Interface at least once. In absence of a good methodology to exactly figure out whether the entire UI is covered, this is usually a big challenge.
3. The cultural changes that need to be tested when one switches from one language to other. E.g. the UI layout, Date/time, sorting etc. would be entirely different in German language as compared to say Arabic language.

So considering these challenges and many such other challenges, the testing approach that is defined for Globalization testing may not always be robust enough to find all major defects. In such a scenario, Exploratory testing plays a very important role in uncovering the defects timely.
I have seen James' Bach's Session based Test management philosophy being successfully used to uncover many hidden Internationalization bugs.


Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
For all the professionally developed International version of Software, the translation of text is carried out by Language experts. Couple of reasons for this-

1. The Language experts being the native speakers of the language are the best judges as to what is appropriate text for the context in which a message/User Interface element is being displayed. It is a real possibility that a Foreign customer may get annoyed if the text is not localized appropriately. Just think of your case, if you are using any Software product in your native language and some text is not localized properly, it would for sure cause for discomfort.
2. Using freely available Online translators may be useful for doing some sort of troubleshooting if you are unaware of language under test. But it is definitely not advisable to log bugs by taking Online translators as Oracle. First of all, the translator software may not be accurate for your context. Secondly, if you still ask the language expert to fix the bug based on the output of online translators, it is highly likely that you may end up annoying the language expert who translated the text for your application.

Watch out this space again till more myths get uncovered!