Click to go to this lesson to add steps to your test. Click to go to this lesson about running your GUI test. Click here to go to the lesson on parameterizing test steps. Click here to go the lesson on creating checkpoints and output values. Click here to go to the lesson on creating and using functions in your test. Click here to go the lesson using Insight object identification. Click to go to this lesson to create object repositories for your test.

Lesson 1: Create a GUI test and actions

Before creating steps to test your application's GUI, you must first create a test and create the actions that provide the test structure.

Each UFT GUI test consists of calls to actions. Actions are units (within the test) that divide your test into logical sections. By dividing your tests into multiple actions, you can design more modular, understandable, and efficient tests.

Your test can contain a number of different types of actions:

Internal and External Actions
  • An internal action is an action that is stored in the local test (also know as a source test).
  • An external action is a referenced call to an action that is stored in a different test.

    An external action called by a test is shown as a separate node under the test node in the Solution Explorer.

For example, if you have an action that you want to use in multiple tests, you would store the action as an internal action in one test and insert calls to that action from other tests. In the other tests which call the action, the action is available as an external action.

Reusable actions

When you insert a call to a new action, it is reusable by default, enabling you to call the action from any test.

When you use reusable actions, you only need to update the existing action stored with the original test. When you modify that original action, all tests containing calls to the action are updated. These reusable actions are read-only in the tests that call the reusable action.

Reusable actions can be useful if:

  • You have a process that you may need to include in several tests, such as logging into your application.
  • You may have a process that you need to insert several times in the same test, such as entering user credential dialog boxes that open whenever a user tries to access a secure part of your application.

If you want to prevent an action from being used in other tests, you can make the action non-reusable.

Copied actions You can also insert a copy of an action in a test if you want to modify the action steps. When you copy the action, it becomes an internal action of the test into which it is copied. These copies are not linked to the source test, so any changes in the original action are not updated in the copy.

Tip: If you plan to use the same or similar actions in many tests, you might consider creating a repository test to store your reusable actions. Then, you can insert calls to these existing actions from other tests.

You add actions to a test in the following ways:

  • Calls to new actions. This inserts a new, empty action in your test. The action is an internal action of the test containing it.
  • Calls to a copy of an action. This inserts a copy of an existing action in your test.
  • Calls to an existing action. This inserts a call to an existing action (an action external to the current test).

Now that you have your test structure, you can begin creating object repositories for the test.

Next steps: