Actions in QTP/UFT with Example

What is an Action in UFT/QTP?

Actions in UFT/QTP divide a test into “logical units” or “business processes”. Each action groups together the steps that perform one recognizable task, such as logging in, searching a flight, or booking a ticket. Actions help create a script that is more modular and efficient.

When a script is newly created, it consists of only one action. You can add more actions to your Micro Focus UFT script as per requirements, and each added action keeps its own logic and local data separate from the rest of the test.

Breaking a long script into actions pays off the moment a test needs to change. A tester can update one action, such as the login sequence, without touching the search or checkout logic that lives in other actions. This isolation also turns actions into reusable building blocks that other scripts can call instead of recording the same steps again.

A typical Flight Reservation script, for example, splits neatly into a Login action, a Search Flight action, and a Book Ticket action. Each one owns its own steps and local data, so a tester who only needs to verify login does not have to record or maintain the booking flow at all.

Types of Actions in UFT/QTP: Reusable, Non-Reusable, and External

UFT/QTP supports three kinds of actions, and the type you choose decides whether an action can be shared across scripts or stays private to the test where it was created.

A reusable action becomes an external action the moment a different test calls it instead of the test that owns it. External actions stay read-only in the calling test because a shared action may be used by dozens of scripts at once, and letting every caller edit the steps would break the others. You can still parameterize the call and work locally with a copy of its Data Table.

As a rule of thumb, keep a new action non-reusable while its logic is still specific to one test. Promote it to reusable as soon as a second script needs the same steps, and expect it to behave as an external, read-only action the moment that second script actually calls it.

How to Split, Copy, and Call Actions in UFT

As an action grows, keeping every step in one place makes the script harder to debug and reuse. UFT lets you split an existing action in two ways once it becomes unwieldy.

• Independent (sibling) split: The selected action divides into two separate actions that run one after another, each keeping its own local Data Table.
• Nested (parent-child) split: The selected action divides into a parent action whose last step calls the second, child action, preserving a logical dependency between the two.

Once actions exist, UFT offers three ways to bring an action into a test from the Insert menu:

• Insert Call to New Action: Creates a fresh, empty action inside the current test.
• Insert Call to Copy of Action: Copies an existing action in its entirety, including checkpoints, parameterization, and its Data Table tab, into the calling test. The copy is fully independent, so edits never affect nor are affected by the original. You can copy both reusable and non-reusable actions.
• Insert Call to Existing Action: Inserts a read-only call to a reusable action stored in another test. It can only be modified in the test where it was created, which keeps every caller in sync and makes large test suites easier to maintain.

Every call compiles down to a RunAction statement in the Expert View:

' Calls Action2, which is stored in Test2, running it for one iteration
RunAction "Action2[Test2]", oneIteration

The action runs as many times as its Action Call Properties specify. For example, if Action2 is set to run on every iteration of Test2’s Data Table but the calling Action1 in Test1 runs only once, Action2 still executes only once, because the call itself is triggered a single time.

💡 Tip: When a test contains several actions, open the Test Flow pane from the View menu to drag and reorder them. This changes the sequence in which UFT executes the actions without editing the steps inside any single action.

The video below builds on the five-step login script created in earlier tutorials for Flight Reservation and walks through creating, splitting, and calling actions end-to-end. It is the longest video in this UFT/QTP tutorial series, so it helps to take notes while you watch.

Click here if the video is not accessible

How to Pass Parameters and Store Output Values Between Actions

Beyond calling an action, most real scripts need to move data into it and read a result back out. UFT gives every action its own input and output parameters plus several ways to persist what it returns.

Passing Parameters to and from an Action

Just like functions or methods in programming languages, an action can define input and output parameters. This parameter has no relation to Test Data Parameterization covered earlier; parameters here belong to the action itself, not to a Data Table column. Configure them from Edit > Action > Action Properties, or by right-clicking the action in the Keyword View. Pass values on the call using this syntax:

' Passes an input value and captures the action's output into myResult
RunAction "Action1", oneIteration, "testuser", myResult

Storing an Action’s Output Value

Depending on what the rest of the script needs, you can keep an action’s returned value in one of three places:

• A variable: RunAction "Action1", oneIteration, "testuser", myResult stores the output directly in myResult.
• An environment variable: create a user-defined variable under File > Settings > Environment, then write RunAction "Action1", oneIteration, "testuser", Environment("env_var").
• A Data Table column: RunAction "Action1", oneIteration, "testuser", DataTable("A", dtGlobalSheet) writes the result straight into the global sheet.

Global and Local Data Sheets

Actions read and write test data through two kinds of sheets. The Global Data Sheet is unique to the entire test; any action can read from it or write to it, and it is always named “Global”. The Local Data Sheet is unique per action, is named after that action, and only its own action can read or write it.

Exiting an Action and Controlling Iteration

When a step needs to stop an action early rather than let it run to completion, UFT provides four statements:

• ExitAction — stops the current action only.
• ExitActionIteration — stops the current iteration of the action and moves to the next one.
• ExitRun — stops the entire test run immediately.
• ExitGlobalIteration — stops the current global test iteration and moves to the next.

While executing a UFT/QTP script that uses actions, keep Global Iterations and Local Iterations in mind, since both affect how many times an action actually runs. You can change how often a called action repeats by opening Action Call Properties > Run tab and setting the iteration mode there.

⚠ Common pitfall: A called action that is set to run on every Local iteration but is triggered from a parent that only runs once will still execute a single time. Confirm both the parent’s Global Iteration count and the child’s Action Call Properties before assuming a called action will repeat.

FAQs