Uncovering myths about Globalization Testing- Reusing Test Automation

Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing

The idea of making a Software test Software without any human intervention is something that is the basis of automated testing. In my experience, i have seen fewer things that catch the fancy of management other than a well crafted Test automation strategy. I was recently studying one of the Surveys listing the success of Software projects across different Software development models. While it is interesting to notice how the project success ratio varies from different Software development methodologies but one important point to note here is that irrespective of the Software development methodology used, the success ratio is far less than maximum. Before i sound like deviating further in this post, the idea here is not to compare how different Software development methodologies fare in the real projects but certainly to draw an analogy that like the success ratio of Software projects, the success rate of Test automation projects (the lifecycle of which is quite similar to Software development projects, though on a smaller scale) is also quite far from ideal. I don’t have a real data to quote here and this inference is quite based on my observations and experience.

While the reasons of Test automation projects' failure can be plenty and its not my intention to dive deeper into those here but in this post i would be focusing on one of the main reasons automation efforts fail to scale up for International languages' testing.
To start with, It’s actually a colossal myth that the test scripts meant for English language automated tests cannot be reused for testing with International languages. I call it "colossal" because the root cause of the automated test scripts for any projects not working on International platform is no less than a design flaw or a lack of forethought at the time of scripts’ design. In my belief, the Software organizations (which went global quite late) have spent sizable costs due to rework relating to introduction of Internationalization quite late in the overall life cycle. On the similar lines as this, Test automation projects have also suffered great deal of rework because the test automation scripts were not Internationalized upfront. Let me try and elaborate what i mean here-

- For a Software product to be properly Internationalized i.e. ready to be sold in International markets- the product design should-
• be Unicode enabled i.e. the product should be able to process and display data in any language
• have all the strings externalized i.e. none of the strings that show up on User Interface should be hard coded.
• have the capability to know under what language OS is it running on i.e. if the product is installed in Japanese, the product logic should recognize that.
• Should be able to read locale specific details from underlying OS
• be robust enough so that the same code base can be used across all the languages that the product support.


- On the similar lines, for Test automation script to be fully internationalized i.e. working successfully on different languages,
• The Test tool should have a capability of being installed and running on different language OS.
• The Test tool and hence, the automated test scripts should have the capability to process the Unicode i.e. any language text and characters. This is because any testing that's done on International test environments makes use of International character sets(which is what the customers would do)
• The Test scripts should have a capability to understand under what language OS is it running.
• The Test data is not hard coded in the Test automation scripts and is Externalized to a file or any database. This helps because, once the Test scripts detects the language of the OS, the "right" language Test data files can be loaded.
• There should not be separate Test scripts per supported language but a single version of Test scripts should be capable to run on multiple languages.

I must admit the above is not a comprehensive list of features required for enablement of Internationalization in automated scripts but i feel it is good enough list to give an idea on things that need to be kept in mind while designing automation scripts which are scalable in multiple languages. Traditionally, the automated scripts are designed keeping in mind that they have to be run on English environments only. To me, that is a sort of cardinal sin because it robs the Software organizations of reaping multi-fold benefits from automation efforts. Consider this- if by automating the English language Build verification tests, the team handling English testing saves 1 man month of effort, it is just a simple mathematics to judge the benefits the same automated scripts will reap if they are designed to run on 10 languages.

In today's global market place, if your product currently doesn’t support International markets that does not mean that it would not in future also. If it is not already, Globalization of Software products would eventually be required for survival of organizations. In such a dynamic scenario, it is imperative that like smart individuals- we think of future possibilities upfront and include Internationalization in our Test automation design right from the word go.

I would be exploring this area further in detail in the upcoming posts and I am keen to hear your views and experiences around Test automation in general and specifically on leveraging Test automation scripts in International environment.