Uncovering Myths about Globalization testing- Input validation testing

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 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing

Introduction:
The testing specific to Input field validation is an important form of testing in any Software application. An example of such testing can be suppose an application having a text field to input Credit card details and a tester can test the same by including various possible inputs to ensure that the valid data is being accepted by the application and the user is presented with a valid message indicating that the input is incorrect.

There are a several techniques that can be used to test this aspect of the application properly. Some available resources listed below-
http://www.testingeducation.com/BBST/Domain.html
Book: Lessons Learned in Software Testing Chapter-3 Testing Techniques Section- "How to create a Test Matrix for an Input field"

What is an encoding system ?:
Though the known techniques do talk about usage of various types of inputs including Language reserved characters e.g. the characters specific to any language that a Software application may be supported such as German, Japanese etc. as these languages do have their own writing systems and character sets. It is of utmost importance to test a Localized application with the language specific characters as any user in any of the product's supported countries would expect the application to support data processing in their own native language e.g. a Japanese user using an email client would expect the application to support writing emails in the Japanese language, otherwise the customer may not find the application worthwhile at all.
One of the important aspects specific to Localized data processing that the known techniques do not specifically talk about is the dependency the Localized data has on the underlying encoding system in the application. If you are new to the term- "encoding system", please read below mini description from www.unicode.org-
Unicode provides a unique number for every character, no matter what the platform,no matter what the program, no matter what the language.
Fundamentally, computers just deal with numbers. They store letters and other characters by assigning a number for each one. Before Unicode was invented, there were hundreds of different encoding systems for assigning these numbers.

Does Unicode have different representations ?:
Unicode is actually an encoding system that encompasses virtually all the known character sets from different languages. There are several possible representations of Unicode data, including UTF-7, UTF-8, UTF-16 ,UTF-32 etc. Each of these different representations have its own advantages and disadvantages depending upon the context e.g.
UTF-8 is most common on the web. UTF-16 is used by Java and Windows. UTF-32 is used by various Unix systems.

Does encoding system representation affect the test data size ?:
One important fact to consider when testing the Input character set for an localized application is to know what type of encoding system is being used beneath. The reason why is it so important to know the underlying encoding system is that no. of bytes occupied for a certain character varies depending upon the encoding system used. Lets take a closer look at this statement by means of an example-
Take into consideration the following character from German language "ä". The byte count of this character depending upon the encoding system used is as follows-
UTF-16 Byte count for "ä"= 2
UTF-8 Byte count for "ä"= 2
UTF-7 Byte count for "ä"= 5

The above example shows that the encoding system do have an dependency on the no. of Bytes for a particular test character.

Different ways of Input text validation- No. of Bytes vs. No. of characters ?:
The next important factor before performing the Input validation testing in Localized applications is to know whether the validation logic is done as per no. of Bytes or the validation is done with no. of characters. Lets take a closer look at this statement by means of an example-
Suppose there is an application with a text field say Username. The usual assumption is that the validation will be done by no. of characters say the "Username" field will support maximum of 10 characters and a minimum of 3 characters.
Suppose a tester uses test data for "Username" as "ääääääääää" and the application is using encoding system as UTF-7. If the validation is done as per No. of characters, then the above is a valid test data as it represents 10 characters. In case the validation is done as per No. of Bytes, then it may not be a valid data (depending upon the Byte limit set), as the test data in the above example may amount to 50 bytes.

Thus, it is important to ascertain before you test to ensure the validation rules.

Summary:
So, before you consider performing the Input validation testing or even generate test data for testing for Localized application ensure that you know about the following-
- Encoding system used by the application
- Validation rule- does the application validates the data as per Bytes or by no. of characters ?

Uncovering Myths about Globalization testing- Demystifying MUI Packs

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 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing

Before we get into the fact underlying this myth, lets get to understand what MUI Pack is and their utility in International software design.

As wikipedia defines MUI-
" Multilingual User Interface (MUI) is the name of a Microsoft technology for Microsoft Windows, Microsoft Office and other applications that allows for the installation of multiple interface languages on a single system. On a system with MUI, each user would be able to select his or her own preferred display language. MUI technology was introduced with Windows 2000."

e.g. lets consider if a user has Windows XP Pro English version running for her usage and for some reason, the user want to change the XP Pro User Interface to German language- this can actually be achieved by installing the MUI pack on English XP Pro which will give the flexibility to the user to change the User Interface language.
One of the practical scenarios where MUI packs can prove to be of great utility is for the support organizations. With the the unique business model that the Software products offers, it takes no time for a successful software product to be made available in different countries (of course after including proper Internationalization engineering). In such a scenario, suppose the product has lot of penentration in German market and at the same time the support organization is located in China. And if Chinese support engineer is troubleshooting the issue online with the German customer, he may need to see the application is in English, German or a more familier Chinese OS environment. This is where MUI packs can help! If the MUI packs are installed, then the support engineer can change the language quite easily at the run time.
Just a note that there's a notable difference in the way MUI was handled pre Vista and pro Vista era. More information here.

With this background about MUI in mind, lets take a crack at the Myth- "Testing International applications using 'Microsoft's MUI Pack' or 'Localized OS installation' means one and the same thing.

In order to test the International software, the Microsoft Operating System setup can be largely created in these 2 broad ways-
1. Microsoft offers different ISOs for different languages e.g. for creating a Japanese Win XP from scratch, one can install Win XP Japanese ISO on the machine and prepare what is being referred to as "Localized OS installation" in the above statement.
2. One more possible way can be installing the English Windows XP and then later on installing the Japanese MUI pack which will result in the User Interface elements to be changed to Japanese.

Though the test setup using both these methods provide a sort of similar user experience but there are some fundamental technical differences between these two types of setups as listed in the table below-










Considering these difference may be there will be certain consistency in the UI display when an application is installed on these 2 different types of setup but I18N testing may result in different results.