After having automated several projects using the OO Framework approach, we've been asked to Internationalize our tests suites. This means the test suites developed by us should also execute when the application under test (AUT)is running on a language other than English. Not only should the test suites 'execute' on a localized version of the AUT, but also find defects!
As a software developer of AUT, the task of internalization/localization is relatively straight forward and the strategy of internalization/localization is well document. The strategy involves moving the language specific string to resource files. Popular languages such as Java & C++ have inbuilt support for this strategy.
When it comes to internalizing automated test suites the stratety is relatively complex. Most of the GUI automation tools work on the basis of 'Object Recognition'. ie. These identify GUI object by a combination of visible string and object properties. Since the visible strings appear in the local language in non-english AUT, the Test scripts developed in english will fail to recognize the objects. This is challenge number one!. Thankfully many of the commercially available tools such as RFT and QTP support internationazing your testware.
Assuming that as a test developer you are able to recognize the GUI objects, the second challenge is that the test developed in English indeed pass in a localized language. Generally, the automated tests compares results with benchmarks ( stored as text files, image files or embedded strings in the script itself ). These benchmarks would be in most cases, language dependent. When internalizing your tests, the task of the test developer is to 'externalize' the benchmark. What's more, the inputs you provide to your AUT will also have to be in a local language. Assuming that the test suites are data driven, its expected to have a 'language version' of each of the data sources.
In most of the cases, you'd not know when language you'd be expected to run the test. That means, as a test developer your test suites should be 'truely language independent' and not say, my test suites is coded for English, Chinese, italian and French only! That's the challenge number three.
In most of the cases, you'd not know when language you'd be expected to run the test. That means, as a test developer your test suites should be 'truely language independent' and not say, my test suites is coded for English, Chinese, italian and French only! That's the challenge number three.
Next blog post I'll explain some strategy to overcome these challanges.
No comments:
Post a Comment