Recording Scripts in IBM Rational Functional Tester

Rational Functional Tester is quite a flexible tool that enables various ways of working. Here I will describe the process of a basic recording in RFT. Some enhancements are added using wizards. At various points in the scenario, options or additions can be clarified. This is done in a limited way to keep the scenario simple.

Before Recording

Before you start recording, you need to take care of several things:

• Be sure the application under test is available including the correct setup of its environment. Doing this results in an expected behavior.
• The application under test must be configured for testing.
• A Rational Functional Test project is created and available. This is the area where you store your work.
• Before recording, you should already have a test script describing the interactions and the points of interest to verify. This can be a manual test script defined in Rational Quality Manager.

When recording, all interactions are captured and converted into the test script. Experience proves that it is wise to stop or disable any interfering programs, such as messaging programs.

Recording

To start recording, click the Record a Functional Test Script button in the Functional Test perspective, as shown in below Figure.

The Record a Functional Test Script button in the default Rational Functional Tester workbench

A new window opens, as shown in below Figure. You need to enter the test script name and the project where it is stored. With the exception of the dollar sign ($) and the underscore (_) spaces and special characters are not allowed for test script names.

Record a functional test script window where you define the project to store the script and define its name.

When you click Next, a second screen opens where some advanced settings can be defined.

When you click Finish, the Functional Test window disappears and the recording window becomes available, as shown in below Figure. From now on, all interactions are recorded! The recording window shows various icons that give access to wizards and functions, such as verification points and data pooling while recording. The recorded interactions are also displayed.

The recording window

Any interaction against the Recording window is not part of the test script. You first have to start the application under test. Select the Start Application icon and then select the application from the drop-down list, as shown in below Figure.

The Start Application window where you can select the application under text. This starts the application and generates the steps in the script.

Selecting OK starts the application. Remember that this action is recorded and it results in an action statement added to the script. This is also visible in the recording window. It is normal for first-time users to perform actions that are not considered part of the intended test script, and as a consequence, results in erroneous recorded steps in the script. All these user errors can be corrected at a later time.

When the application under test is open as shown in below Figure, you can perform required test steps. First select composer Bach, and then specify the CD selection. Click the Place Order button and log in as the default user.

The ClassicsCD application

To validate expected execution of the application under test, the test script must be enhanced with check points called verification points. A verification point is a check that the current execution corresponds with your expectations, which is called the baseline. A difference between actual and baseline results in a fail status in the execution log. Differences in the consecutive application builds that are not checked with a verification point are not captured and do not result in failures. It is best practice to verify only what makes sense because verification points act as your eyes.

The Verification Point icon shown in below Figure enables access to Verification Point. Let us say that we need to verify that the total price is $15.99. While recording, select the Verification Point icon on the recording window.

The Verification Point icon gives access to the verification points.

The Verification Point and Action Wizard is displayed as shown in below Figure.

The Verification Point and Action Wizard gives you the options to identify the object to be verified.

Drag the hand icon over the $15.99 value. As a preselection, a red square is drawn around the object, as shown in below Figure. When you release the cursor, this object is selected.

When you drag the hand icon to objects, Rational Functional Tester provides a preselection for easy identification.

When you release the cursor, the properties of the object selected become visible at the bottom of the wizard. You can validate that you have selected the correct object. Click the Next button to advance to the next window. In this window, you define what kind of verification point has to be created; following are the available options:

• Data Verification— Use this for validating the actual data in an object.
• Properties Verification— Use this for validating one or more properties of an object (for example, if it is selected or it is color).
• Get a Specific Property Value— Use this to get a specific property value into a Java variable.
• Wait for Selected Test Object— Rational Functional Tester waits until this object becomes available. Use this as an intelligent mechanism to synchronize with the application under test.
• Perform Image Verification Point— A graphical verification point.

This scenario uses the Data Verification Point. Click Next. In the next screen, you can give an appropriate name and influence the default wait for settings. Click Next. You can see data here and make modifications if necessary. Click Finish. The Data Verification Point is created and inserted as code in the program. You can continue recording the interactions. While recording, you can add various verification points.

After closing the application under test, you have to stop recording by clicking the Stop Recording button in the Recorder window. When it is selected, Rational Functional Tester’s main screen displays and test script is created.

After Recording

After recording, you can improve the recording by:

• Adding comments where possible. Any tester should be able to read test script and understand the logic.
• Correcting the user’s mistakes, which were recorded and converted into statements.
• Correcting the actions by removing the recorded errors and backspaces.

Validating Execution

A first validation of correctness must be done by executing the test script against the environment where it was recorded. Keep in mind that not only the application is under test, but so is the test environment, which should be reset to its original state. For example, a double creation of the same customer probably results in an execution error.

Timing Issues

It is common for an application to be slower than the Rational Functional Tester expects. For example, an interaction with a web page might be hindered by slow network traffic. This results in a problematic execution. In this case, you have to slow down the execution. Several options are available:

• Get an overall slowdown using the Rational Functional Test parameter shown in below Figure.
• 

The overall slowdown parameter for Rational Functional Tester; 30 is roughly 1 interaction per second. Reset it again when running in production.

• Add hard sleep statements: sleep(2.0);
• Add wait-for-existence: ObjectInApplication().waitForExistence();
• Lengthen the wait-for parameters in waitForExistence or VerificationPoints: ObjectInApplication().performTest(ObjectSubmit_textVP(), 2.0, 40.0);