Skip to main content

Using IBM Rational Functional Tester to automate testing of globalized applications

Komal Mirchandani
Komal Mirchandani is currently working as Software Engineer for IBM Rational where she is responsible for ensuring the quality of Rational TestManager and Rational Functional Tester. She has been with IBM Rational for around 3 years and has almost 5 years of industry experience. Her core skills comprise of estimation, design and execution of GUI test automation projects. She also has expertise in the QA, test automation and administration of enterprise applications and workflow products like ClearQuest. She has participated in various external customer engagements and has been continuously participating and presenting in various forums like: QSE, QAI, and TechConnect.
Shruti Ujjwal (shujjwal@in.ibm.com), Software engineer, IBM
Shruti Ujjwal
Shruti Ujjwal is a Prinicipal Software Engineer at the IBM Rational - India Software Lab, Bangalore. She works as part of the System Verification Testing Team and is responsible for testing Rational Functional Tester. She has strong automation background and is driving automation initiatives within Rational SVT organizations using the IBM-ITCL framework. Additionally, she has got expertise on Mercury's Quick Test Pro, Mercury's Winrunner and White Box testing with Frameworks like: JUnit and XMLUnit. She also holds Brainbench Certification in Winrunner and Software Testing. She has been actively involved in various customer engagements and problem solving sessions throughout her stay in IBM. Additionally she has participated and presented in various forums like: QSE, RSDC, QAI, TechConnect, and for various teams in IBM-ISL and IGSI.

Summary:  If you want to develop test automation scripts for globalized applications, but you are having difficultly because the automated scripts recorded on a particular location fail when run at another location, this article will help. It explains an approach that enables you to seamlessly run a test automation suite developed in IBM® Rational® Functional Tester across different locations. The test automation engineer simply has to be a little more cognizant of the object properties to be able to use that knowledge in the test suite development for localized applications.

Date:  25 Sep 2007
Level:  Advanced
Activity:  836 views

Prerequisites

  • Installation of IBM Rational Functional Tester Version 6 or 7, along with the necessary language packs.
  • Installation of operating system language packs for all of the necessary locations, depending on the requirements (Japanese, Chinese, and French, for instance).

An overview of test automation

Manual testing is time-consuming, labor-intensive, and frequently monotonous. It introduces problems, especially when there are limited resources and stringent deadlines. If you need to improve your application testing make sure that it works without a hitch, it's important that you move toward automating all of the manual testing tasks.

In today's environment of reduced cycle times, automated testing empowers both professional and novice users to quickly achieve high-quality results from application testing. Automation tools record user interactions against an application, and the scripts derived from these are then used for subsequent tests. In a nutshell, test automation enables you to optimize the quality of the complex application in a cost-effective manner within the timeline. This helps you produce higher quality software faster.

By using IBM Rational Functional Tester as a test automation tool, test automation is a three-step process::

  1. Record: Recording test scripts on the fly, as users navigate the application. You can also insert verification points to validate system response, and make test scripts data-driven to execute the same script on a variety of data inputs.
  1. Enhance: Adding code is to perform a variety of functions. Typical modifications to enhance test scripts include conditional branching, refactoring, and exception handling.
  1. Play back: Running scripts to emulate the same actions that a user has performed on the application under test while recording. Discrepancies are logged and the tester can conclude whether functionality works fine or regression bugs have been introduced.

Typical problems in globalizing test automation

There are several challenges that a test automation engineer faces due to the changing software deployment trends. The current trend is that software development organizations and customers using them are geographically distributed, which means that applications must be globalized.

Globalized applications are those in which all of the strings, such as messages, labels, and text, are localized, that is, translated to the language of the location from which it was started or launched. For example, if an application is started from a Japanese locale or operating system, then all of the information will appear in Japanese. Similarly, if an application is started from a French locale or operating system, then he Information will appear in French, and so on. "Globalized" also refers to applications that allow input and output of a non-English character set.

The result is that, even after successful automation of such globalized applications, you may encounter these problems:

  • Automated scripts recorded for a particular locale fails when played back in a different locale. This happens because the object definition used for playing back the automation script (for instance, the label of the button on which the automation script has to operate) may be different from an English to a Japanese locale. (See Figure 1.)
  • Verification points checked in a particular locale fail when you attempt to affirm them in a different locale. This happens because the expected or initially recorded value of the verification point does not match the actual value displayed in the globalized application under test, because it was launched from a different location.
  • Data-driven test scripts do not pick and populate the data set, depending on the location from which the application under test was launched. This happens because there is no implicit intelligence built into the automation script to help determine the language.

For example, Figure 1 depicts a globalized application that is launched initially on an English locale for recording the test scripts. The same script is later played back when the application is launched in the Japanese locale, but the script fails because the messages on the application under test were recorded in English. However, when the same application is launched in a Japanese locale, the messages get translated into equivalent Japanese text resulting in change of underlying object properties.


Figure 1. Script recorded in one locale and played back in another fails
illustration of script execution scenarios in diferent locales

Problem: Record/Playback model fails
Reason: The application under test is globalized

  • Recorded on Locale 1 (English, for example)
  • Played back on Locale 2 (Japanese, for example)
  • Result: Script fails
  • Reason: The object definition used for playing back the automation script is different for various locations.

Similar problems can occur with verification points and data-driven test scripts.


How automated testing of globalized applications works

A globalized application uses local resource files to show localized messages, labels, and text in the same application that will be launched from different locations. The approach described here is based on IBM Rational Functional Tester, and it uses the locale resource files that are shipped with the globalized application. The locale resource file maps one-to-one between the object’s property value and the variable corresponding to that value. This helps in picking the equivalent value of text from the resource file, depending on the locale from which the application was launched at the time of playback.

If you plan to globalize your test automation suite, you must deal with these object maps. The object map is nothing but a collection of all of the GUI objects in the application under test, with corresponding property values. You must select the property value (for example, the label of the button) and find the corresponding variable for it in the resource file (Figure 2). After the object property value is replaced with this variable, an underlying code fetches the value of the variable according to the current location (Figure 3).


Figure 2. A graphical representation of object mapping
diagram of property substitution for an object


Figure 3. The underlying utility that enables automated testing of globalized applications
diagram of reset object properties

When the script is played back hereafter, rather than looking into the property value (which differs for each locale), Rational Functional Tester uses the variable, which is the same across locales. Thus, the script plays back smoothly. This approach makes the test automation scripts reusable and resilient to locale changes. It also allows automation scripts to surface defects in globalized applications without the extra effort of manual globalization testing.

Steps to automate testing of a globalized application

To implement this approach, start with a sample Java™ foundation class (JFC) button globalized application. The accessibleName and name Properties of this JFC button are localized, which indicates that the value corresponding to these properties will depend on the locale from which the application is launched.

Figure 4 shows how a globalized application is built and packaged. In this case, the JFC button application is an executable Java™ Archive (JAR) file. It has source code built as Java classes and is bundled with various locale resource files that make the text on the application translatable. Thus, when this application is launched in different locales, the text appearing on the user interface is read from the corresponding resource file in that locale. This is what makes an application globalized.


Figure 4. Structure of a JFC button globalized application
Schematic diagram of executable

Record

To automate any globalized application that is recorded in just one locale and played back in different locales (such as Japanese, Chinese, or French), follow these steps:

  1. Set the Enable Localization variable to True (rational.test.ft.services.enable_localization=true) in the ivory.properties file, which is available from the Rational Functional Tester installation location. (See the code in Listing 1.)

Listing 1. Snippet from the ivory.properties file, with the Enable Localization variable set to True
                
###
### Internal properties: Not intended for consumer modification
###
# Version number applied to the enabler.wsw plugin when an eclipse shell gets enabled
rational.test.ft.enabler.plugin.version=7.0.0
# rational client JVM startup options
#rational.test.ft.client.jvm_options=-xj9
# When enabled this option allows the install directory for the local
# TestContext to differ from the global setting
# (the install directory of the first TestContext created)
rational.test.ft.install_dir.ignore_mismatch=true
# When enabled this option allows recording / playback against product own UI
rational.test.ft.testability.allow_testing=true
# When enabled this property allows string lookup in the localized
# string table, if available 
rational.test.ft.services.enable_localization=true
# Internal. Allow connecting to a .NET project for execution framework testing
#rational.test.ft.testability.allow_vbnet_remote=true


Step 2 leverages the use of IBM® framework (formerly known as ITCL) to develop test scripts in Rational Functional Tester. Using this framework ensures a structured approach to developing test script, and also offers other advantages: A layer of abstraction to the test automation scripts by organizing them into AppObjects, tasks, and test case layers. Minimized complexity and test scripts that are reusable and generic. A base set of library files that provides generic functionality to the automation harness for test script development and extension.

  1. Use the IBM framework to organize the Rational Functional Tester script developed for the JFC button globalized application into three layers (shown in Figure 5):
    • appObjects layer: Creates a class called appJbutton, which is where the objects that the test script will interact with are stored.
    • tasks layer: Creates a class called taskJbutton, which is where the actual logic is written in form of various tasks, also known as functions.
    • testCases layer: Creates a class called testCaseJbutton, where the various tasks written in the tasks layer are used to make an end-to-end testing scenario.

Figure 5. Using the IBM framework to organize the Rational Functional Tester scripts
diagram of framework library structure and associated script layers

  1. Record a script for any locale (English, for example) by using Rational Functional Tester.
    1. Identify all object properties with values that vary in different locales.
    2. Now open the object definition file, which is known as the object map in Rational Functional Tester.
    3. Choose the object property with the value that differs in various locations. In the case of this sample application, the accessibleName and name properties of the javax.swing.Jbutton object vary (see Figure 6).

Figure 6. Object map of a globalized application, object property with a varying value selected
image of object definition workspace

  1. Search the object property value in the JFC button application resource file. In this case, the varying object property value is Remove text. This is the value in the English locales, and there is equivalent text in each of the other locales (see Listing 2 and Listing 3).

Listing 2. Snippet from the English resource file for a key-value pair (variable-property value)
                
# NLS_MESSAGEFORMAT_VAR
sampleapp.remove = Remove



Listing 3. Snippet from the Japanese resource file for a key-value pair (variable-property value)
                
# NLS_MESSAGEFORMAT_VAR
sampleapp.remove = \u9664\u53bb(E)


Enhance

  1. Replace the value in the Rational Functional Tester object map with the corresponding variable name found in the resource file. In this case, the property values for Properties: accessibleName and name of the javax.swing.Jbutton object was Remove text. This is replaced by the variable name sampleapp.remove, because this is the key corresponding to the Remove value (Figure 7).

Figure 7. Object map before (with property value) and after (with property value replaced with variable from resource file)
image of object mapping

  1. Place a copy of the all the localized application resource files under the project's resources folder.
    1. Change the name of all the locale resource files so that they start with the Rational Functional Tester project name and include the locale names. In this example, these locale resource files are renamed to start with BeyondlocaleBarrier (because that was the project name) and then the respective locale names are added to the file name (see Figure 8).
    2. Thus, for example, the file name for Japanese becomes: BeyondLocaleBarrier_ja.properties. This ensures that the value corresponding to the variable assigned to the object property, as shown in Step 5, is picked by the Rational Functional Tester scripts for appropriate recognition of the objects during playback.

Figure 8. Localized application resource files placed under the project's resources folder
image of application resource folders

  1. Write a National Language Support (NLS) utility (as shown in Figure 9) that:
    • Accepts a variable corresponding to an object property value.
    • Checks for current locale (Japanese, for instance).
    • Searches for the current locale-specific resource file.
    • Searches for the variable in the resource file.
    • Returns the localized value:
      • Set it as object property value for correct recognition using the setProperty() API.
      • Use it for required conditional checks or verification points (Figure 10)

Figure 9. The NLS utility written to test the JFC button globalized application
image of sample utility


Figure 10. Leveraging the use NLS utility to perform a conditional check or verification point to ensure that the expected button name matches the actual one
image of sample utility

Play back

  1. Play back the script on various locations, such as Japanese, Chinese, and French, and the test script will run successfully because it is now locale-independent (see Figure 11 and Figure 12)

Figure 11. Rational Functional Tester playing back the test script on an application launched in a Japanese locale, which is different from the one where it was recorded
image of launched application

Note:
With the use of the NLS utility, even though the script was recorded in an English locale, it passed in a Japanese locale


Figure 12. A Rational Functional Tester script playback log for an application launched in a Japanese locale
image of playback log

Advantages of this approach

There are several advantages of developing an automation harness for globalized applications, using the approach described in this article. A few of them are listed here:

  • Globalization regression testing
    • Test automation teams can leverage this approach to build an automated regression test harness to test globalized applications build after build.
  • Record once, play anywhere
    • Teams can develop automation scripts in an English locale and run the same script in other locations (Japanese, Chinese, French, and so on) without any modification to the script.
  • Using your time wisely
    • If the test automation effort in one locale was, say, X days (for one tester), the test automation effort in nine locales will be 9*X days.
    • By automating globalized application testing using IBM Rational Functional Tester, the time spent will be a maximum of 2*X days.
  • Easy maintenance
    • If there was a text or label change in application under test, only the resource file was replaced, rather than having to change the automation scripts. This enables one-point updates of objects and their corresponding properties.

Resources

Learn

Get products and technologies

Discuss

About the authors

Komal Mirchandani

Komal Mirchandani is currently working as Software Engineer for IBM Rational where she is responsible for ensuring the quality of Rational TestManager and Rational Functional Tester. She has been with IBM Rational for around 3 years and has almost 5 years of industry experience. Her core skills comprise of estimation, design and execution of GUI test automation projects. She also has expertise in the QA, test automation and administration of enterprise applications and workflow products like ClearQuest. She has participated in various external customer engagements and has been continuously participating and presenting in various forums like: QSE, QAI, and TechConnect.

Shruti Ujjwal

Shruti Ujjwal is a Prinicipal Software Engineer at the IBM Rational - India Software Lab, Bangalore. She works as part of the System Verification Testing Team and is responsible for testing Rational Functional Tester. She has strong automation background and is driving automation initiatives within Rational SVT organizations using the IBM-ITCL framework. Additionally, she has got expertise on Mercury's Quick Test Pro, Mercury's Winrunner and White Box testing with Frameworks like: JUnit and XMLUnit. She also holds Brainbench Certification in Winrunner and Software Testing. She has been actively involved in various customer engagements and problem solving sessions throughout her stay in IBM. Additionally she has participated and presented in various forums like: QSE, RSDC, QAI, TechConnect, and for various teams in IBM-ISL and IGSI.

Comments (Undergoing maintenance)



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=256567
ArticleTitle=Using IBM Rational Functional Tester to automate testing of globalized applications
publish-date=09252007
author1-email=komal.mirchandani@in.ibm.com
author1-email-cc=rhalden@us.ibm.com
author2-email=shujjwal@in.ibm.com
author2-email-cc=rhalden@us.ibm.com

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers