Understating Localization Testing Approach For Windows Phone 8+ Apps

What comes first in our mind after hearing the word ‘Localization’?

Answer would be like it’s simply the act of making something local.

Before knowing about the approach of localizing a Windows Phone app and its testing one should know about following things:

Local:

A locale is a region setting that usually operates independently of language. For example, you can set the date, time, currency, and number formats to say French on your Windows phone. Your locale would be set to fr in this case.

When it comes to language, you need to set your language to French if you wanted to see everything in that language.

Language and locale are two different things. I could be a French speaking person living in the India. My Windows Phone app UI is all in French, but my dates, currency, numbers etc. would all need to be in Indian format.

Translation:

Translation is the process of collecting a word or string from one particular language and displaying it into another language. Translation is nothing but a process for converting a thought from one language into another. 

Internationalization:

It is the process of building your app so that it will work across all regions of the world in which the app is made available. An app might only be available with an English user interface, but it should work for someone living in France as it works for someone lives in India.

Localization testing follows after product localization and is performed to ensure that the localized product is fully functional, linguistically accurate, and that no issues have been introduced during the localization process. Localization testing involves testing of the localized product in accordance with national language standards, searching for un-translated text in the user interface, verifying consistency of formats (date formats, number formats, etc.), verifying accordance with capitalization rules and proper use of alphabets, verification of correct use of currencies, etc.

Before getting started with the localization testing approach for Windows Phone apps, let’s see in brief how a Windows Phone app is localized,

While developing the app developers uses the resource files i.e. .resx files to maintain the localized strings of a text to be shown in an app. There is a separate .resx file is maintained for each language and it will be picked up automatically depending on the language selected on the device.

To change the language of the Windows Phone device:

1. Go to Windows Phone settings section:

2. Select language + region

3. Change language settings to the language you want

    

4. Press restart phone button

5. After restarting the phone open the app

Now you are good to go with the testing part of localized Windows Phone app.

There are several methodologies/techniques that one can use to test localization of apps. I prefer following approach while testing the localization of app on any platform (Windows Phone, Android, iOS).

Phase 1: Making sure string being used for localization are correctly localized

First of all make sure that the string which you are going to use for different languages are meaningful and that you can test with use of different translators such as Google translation service or IBM’s translator. These tools are very helpful to make sure your strings are correctly spelled and are meaningful. Once the strings are verified on our end then developers will start localizing the apps using those set of strings.

Phase 2: Making sure core functionalities are working as expected

After dev complete at first QA has to make sure all the core functionalities are working E2E. During testing these scenarios you are making sure that all the core functionalities are intact and not broken by introduction of localization. Also one may encounter the functional issue and app crashes during this phase.

While testing the localization of Windows Phone  apps I observed many such crashes for these apps initially after dev complete.

Phase 3: Cover stack/heuristics

Moving onto the stacks/heuristics test all the scenarios where app behaviour changes in different time zones. If there is any functionality having dependency on time and regions then here you will be making sure that core functionality of these specific scenarios is intact.

This was very interesting part that I observed while testing localization, in one of the app, it was observed that application behaviour was working as expected on choosing the region and associated time zone. However the application behaviour was unexpected when correct time zone was not selected.

If you are supporting multiple languages for the app and QA has time limits to complete it early then it is difficult to cover all the things by your own. So during this phase QA it would be better if QA conducts bug blitzes (Bug Blitz: It is kind of bug bash where multiple QA folks come together and work on a particular part/ workflow of an application to find bugs) for each language and collect the results for the executed scenarios from all the participants. This way we can cover the core functionalities for multiple languages in parallel.

Since I was working on 4 Windows Phone apps for a release, I conducted around 4 Bug Blitzes in a week for 2 consecutive weeks, for each app covering 10 languages per app. This way I was making sure whatever I have covered in Phase 2.

Phase 4: UX testing

Once you are done with testing of all core functionalities of the app and the time zone related testing of app we are good to proceed further with UX testing part. QA should go through all the pages in the app and make sure that strings are localized correctly or not. This is not a simple process to test so any UI automation tools can be used in order to get this tested faster and accurately. This way you will encounter the issues like special/junk characters in translated text, string truncations, sentence/ word wrapping etc.

This phase of testing takes much more efforts than above phases of testing as it depends on the complexity of an app, more number of screens/pages used in an app more the efforts required.

Although automation cannot substitute for manual testing when we talk about localization. It can be useful to avoid human errors when trying to reach a particular dialog and it is very good as help for translators not very skilled in computers. It also saves a lot of time, as you can run setups during the night, so all the environments are ready by the time testers arrive in the morning. But you need the tester or the translator to manually check the final dialog your automated script can reach.

To complete this phase of testing there is a very great and standard way of verifying the strings across all the screens/pages of an app, i.e. Localization UX Checklist. Sample checklist that I have used for verification of the strings/description on each screen/page of the app is below.

Here I have created a separate sheet for each of the Windows Phone app for which I want to test localization. Then I verified each screen of the app for each supported languages using this checklist and marked the completed ones with Y or N letters. Here Y stands for YES and N stands for No for requirement - Is string shown as expected on the current screen? You can also share this Localization UX checklist -sheet on Google drive/ SkyDrive with the participants in the UX Bug Blitz to get the results faster.

There is a term numeronym used in the industries for identifying this computing,

There are several numeronym  that are used  like L10N is a numeronym for ‘Localization’ where the 10 letters ‘ocalizatio’ have been replaced by the number 10 in order to indicate that there are 10 of them. Similarly, T9N, I18N and G11N are numeronyms for ‘Translation’, ‘Internationalization’ and ‘Globalization’ respectively.

So localization testing is very important when the customers using your product/application are across the world and to provide them a good user experience of your application in their language and time zone.

Happy reading and localizing…