Enhancing Rational Functional Tester’s default synchronization can be as simple as adding a generic delay to your script. You can use the sleep() method (Sleep() function in the .NET version). This is available to you while recording or via coding.

When you are recording and notice that your application is slow to respond, you can turn to the Script Support Functions button on your toolbar. This is shown in below Figure.

Script Support Functions button on the Recording toolbar

Engaging this button provides you with the option to place a sleep() method into your script. Have a look at the below figure for a visual reference.

Script Support Functions Sleep tab

To use this function, you specify the number of seconds that you think your script will need to handle any latency issues with your application. You then click the Insert button. If you were using the Eclipse version of Rational Functional Tester, you would see a line in your script that looks like the following:

sleep(2.0);

Otherwise, using the .NET Studio version of Rational Functional Tester, you would see:

Sleep(2.0)

The code below shows what these lines look like in the context of a test script:

Java

public void testMain(Object[] args)
{
startApp("ClassicsJavaA");

// PAUSE EXECUTION, USING sleep() METHOD, FOR 2 SECONDS
sleep(2.0);

// Frame: ClassicsCD
tree2().performTest(VerifyComposerListVP());
classicsJava(ANY,MAY_EXIT).close();
}

VB.NET

Public Function TestMain(ByVal args() As Object) As Object
StartApp("ClassicsJavaA")

' PAUSE EXECUTION, USING sleep() METHOD, FOR 2 SECONDS
Sleep(2.0)

' Frame: ClassicsCD
Tree2().PerformTest(VerifyComposerListVP())
ClassicsJava(ANY,MAY_EXIT).Close()
Return Nothing
End Function

If you execute either of the scripts displayed in Listing 3.1, execution pauses when it hits the sleep() method. The duration of the pause is determined by the number of seconds that was specified in the argument to the method (the number in the parentheses). In the case of the examples in above code, execution pauses for two seconds.

You also have the ability to code these lines directly into your scripts. For instance, you might not have recorded these delays because you didn’t experience poor performance with your application while recording. However, upon playback of your scripts, you see periodic latency issues that surpass the default synchronization built into Rational Functional Tester. Using, the playback logs, you can find out what object was unable to be found on playback. This enables you to go into your script and code in the necessary sleep() lines. Please remember that you need to provide, as an argument to the method, the number of seconds to pause. This should be a floating number (for example, 2.0, 3.5, and so on).

The benefit of using the sleep() method is that you can now place extended synchronization capabilities right within your scripts, freeing you from the dependency of global playback settings. The downside of using the sleep() method is you are dealing with a static period of time. In other words, your script has to pause for the specified period of time regardless of whether or not the application responds faster than anticipated.

The Storyboard Testing feature includes additional preferences you can modify. I will describes each preference and give an example of how that preference affects your script when the preference is checked and when it is not checked.

Preferences for Application Visuals

The Storyboard Testing preference can be expanded in the left-hand navigation area of the Preference dialog box. Expanding it shows a selection that enables you to change preferences for Application Visuals, as shown in below Figure.

The options within Storyboard Testing for Application Visuals

If this preference is unchecked, the other preferences are not available.

Enable Capturing of Application Visuals

By default, Rational Functional Tester captures application visuals while you are recording. If you click the check box to deselect this preference, application visuals are not recorded for any script you subsequently record. You need to rerecord the script to add application visuals to it. Deselecting this preference also causes the other preferences for Application Visuals to be grayed out.
Insert Data-Driven Commands

If you select to insert data-driven commands, a datapool is associated with your script during recording. As you interact with objects during recording, you can add the objects to the datapool as columns, and the statements include actions to retrieve the data from the datapool instead of using the data you type.

Show Verification Point Dialog

If you select to show Verification Point dialog, the Verification Point wizard dialog box will be presented when you are selecting the Data Verification Points using the Application View.

Enable Capturing of Verification on Test Data

Select the check box to enable the option to capture verification on test data, and during recording, Rational Functional Tester will capture and persist all the verification point data associated with the object available on an application under test page. This will allow you to insert Data Verification Points using the application visuals displayed in the Application View.

Storyboard Testing is enabled by default in Rational Functional Tester; you do not need to do anything to be able to use it unless it has been disabled in your installed copy of Rational Functional Tester.

How to Enable Storyboard Testing

To enable Storyboard Testing, first open the Preferences dialog box by clicking Window > Preferences. In the dialog box, expand Functional Test in the left navigation pane, and then click Simplified Scripting, as shown in below Figure. Finally, click the Apply button to save this preference. If you have no other preferences to change at this time, you can click the OK button to close the dialog box.

The option in Functional Test preferences to enable Storyboard Testing

Considerations for Enabling Storyboard Testing

When you check this preference, from that time forward, all new scripts you create (whether by recording or by editing an empty script) use Storyboard Testing. To return to the traditional perspective, uncheck this preference and all new scripts are recorded and edited in the traditional manner until you change this preference again.

This preference has no effect on scripts that already exist; Rational Functional Tester stores the type of script (Storyboard Testing or traditional) with the script, and opens the appropriate views in the Functional Test Perspective. You can edit Storyboard Testing scripts alongside traditional scripts within the same running instance of Rational Functional Tester and as you switch between the different script types. As you select a different type of script, the Functional Test Perspective changes the views to match the type of script being edited.

The Storyboard Testing feature includes additional preferences you can modify.

Storyboard Testing is a new feature introduced in Rational Functional Tester version 8.1. Its purpose is to enable automated test creation by testers who might have significant subject matter expertise with application under test but might not have programming skills.

Original look at Test Automation

Initially, all test automation was done by programming. To use those early tools, testers had to learn a programming language and become proficient at it. This was a barrier for testers who might have had expertise in the subject matter of the business, but who had no training in programming.

Record-and-playback technology enabled non programmers to create automated test scripts and execute them. However, if the application being tested was changed (as one would expect it would be in the course of maintaining it), then the test scripts often needed to be recorded again. Unless the automated script was executed frequently, the savings of a tester’s time through test automation would decrease because maintenance of test automation required almost as much time as executing the tests manually.

The use of wizards simplify tasks, which otherwise require or re-programming, but also for other tasks, the only recourse was to learn the language, or assign the task to someone who does not know the language. Again non-technical user was shut out.

Whether the script was programmed or recorded, the fact that the script was represented as a program required the tester to visualize what the application looked like at each statement of the script, rather than by seeing the interface itself. This also tended to favor those with programming backgrounds because this kind of visualization is an essential part of a programmer’s training.

Overall, test automation required too much skill in programming. Subject matter experts needed an easier way to create test automation, one that would not require them to become coders.

Rational Functional Tester provides this easier way. Storyboard Testing enables nontechnical users to see their scripts in a human language instead of in a programming language.