Understanding Localization Testing Approach For Windows Phone 8+ Apps

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 for 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  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 in 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 who 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 use 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 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

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 strings 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 development is completed, the QA has to make sure all the core functionalities are working E2E. During testing these scenarios, you are making sure that the core functionality is intact and not broken by introduction of localization. Also one may encounter functional issues and app crashes during this phase.

While testing the localization of Windows Phone with a leading MDM enterprise solution. I observed many such crashes for these apps initially after development is completed.

Phase 3: Cover stack/heuristics

Moving onto the stacks/heuristics test all the scenarios where app behavior 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, it was observed that user is receiving the emails successfully on choosing the region and its associated time zone. However the emails were not syncing for the same mailbox when correct time zone was not selected.

If you are supporting multiple languages for the app and QA has limited to complete the testing, then it is difficult to cover all the things by your own. So during this phase of 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 of an application) 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.

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. 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. The higher the number of screens/pages used in an app the more are the efforts required.

While automation cannot be a 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 language 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.

Numeronym is used in the industry to define a number-based word.For Localization the  Numeronym are is L10N , where the 10 letters ‘ocalizatio’ have been replaced by the number 10 to signify 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 across the world.  It provides them a good user experience of your application in their language and time zone.

Happy reading and localizing…