Test Automation for different Locale?

Question

I have begun with automation for a product which is in one language and soon to be ported in another. The only good thing is - Test Automation is just begun.

So there are two things which worry me - hard coded Strings (app title, alert messages etc) in Test Scripts and Test Data which should be keyed in depending on locale.

I was thinking of having a global variable which indicates the locale for which test is to be executed and then deciding on String/test data to be used in test method.

Now consider that I externalize the String I have in tests and then decide string of which language is to be used in my test method, so I could do something like -

 public void myAweSomeMethodWorkingInAllLocales() { 
   if(locale is fr) {
     testDataFile=privateLocation/frTestDataForThisLocale
     testStringFile=privateLocation/frAPPStringForThisLocale
   } else if (locale is in) {
     testDataFile=privateLocation/inTestDataForThisLocale
     testStringFile=privateLocation/inAPPStringForThisLocale       
  }
  //Carry Out my Super tests here
  }

But I find it little cumbersome to do so in each test method of mine. Could I improve it?

Answer 1

There are many other aspects to testing internationalization and localization, and other ways to attack problem I think you are trying to solve, but I will restrict my answer to your specific question.

I suggest removing all hard-coded locale references from your test suite, and instead having the entire test suite test against a single locale that you specify via a command-line argument, property file, or environment variable. Then, instead of doing this...

if(locale is fr) {
  testDataFile=privateLocation/frTestDataForThisLocale
  testStringFile=privateLocation/frAPPStringForThisLocale
} else if (locale is in) {
  testDataFile=privateLocation/inTestDataForThisLocale
  testStringFile=privateLocation/inAPPStringForThisLocale       

}

... I would do this:

 testDataFile=getTestDataForThisLocale(the-locale-we-are-testing-this-time)
 testStringFile=getAppStringsForThisLocale(the-locale-we-are-testing-this-time)

If you want to test two locales, you can run the test suite twice. This gets you out of the business of embedding locale-dependent if-statements throughout your test suite.

Answer 2

I blogged about this a while back here. These are some of the pitfalls I encountered when developing test automation solutions for a product available in 28 languages.

I would NEVER hard code any strings - really your automation shouldn't depend on them at all. Depending on the architecture of the product under test, you should get buy in from development to ensure that each control on the UI has a unique, static identifier. For example, for a HTML based UI, the 'id' attribute could be used. Win32 controls can be assigned identifers also I believe.

Maintaining strings files is a bad approach, if the strings change (for example in a new version or a bug fix due to bad localization), you'll need to update such files.

If you use a unique identifer of some sort, your automation will possibly work for many versions, unless in the event of a major UI overhaul.

Answer 3

If your application supports Unicode then I really don't understand the reason for segregating input or output test data by language or language family. If somewhere in your product code you thunk between ANSI and Unicode then you could certainly have some issues and testing with a broad range of chars across the Unicode spectrum will flush out those problems sooner than by language based resources.

But, this is especially the type of situation where random test data generation becomes valuable; even locale specific test data. Instead of jumping through a bunch of else if's or switch/case statements you can pass the 'locale' argument to "GetString()" method that takes a language/locale parameter.

A well designed random string generator can generate strings by language family, language, etc, or a mix. I am also working on one now that will generate look like real sentence, or take bodies of text from locale specific docs, randomize the words and spit out sentences, paragraphs, etc.

Alternately, if you are using static files to read in your test data you can also let the system do the work. If you have a file named with each locale / language code you can detect the current language code programmatically, then just read in that file.

            string testDataFileName = "testdata.txt";

        CultureInfo ci = CultureInfo.CurrentCulture;
        string isoLanguage = (ci.ThreeLetterISOLanguageName);

        string path = Path.GetFullPath(
            Environment.GetFolderPath(Environment.SpecialFolder.Desktop));
        try
        {
            using (StreamReader readFile = new StreamReader(
                Path.Combine(path, string.Concat(isoLanguage, testDataFileName))))
            {
                //do stuff
            }
        }
        catch (FileNotFoundException)
        {
            // handle file not found exceptions
        }

In this case I am getting the 3 letter ISO language name (the complete list is at http://www.loc.gov/standards/iso639-2/php/code_list.php), and prepending it to a filename or extension and then using stream reader to open and read in the file's contents.

This eliminates the need for passing command line args at the launch of the test, and enables growth into new locales as needed by simply adding new satic data files.

Answer 4

Years ago, I took a similar approach to testing under different locales. It worked well for me.

I used something like this during the internationalization portion of the project: http://strazzere.blogspot.com/2010/04/pseudo-translation-of-strings-as-aid-to.html

I also externalized all the resources (strings), and had them translated for me by a professional translator.