How to Record and Playback UFT/QTP Script
Thomas Hamilton
⚡ Smart Summary
Recording a UFT One script captures each action you perform on the application as a test step, and playing it back replays those steps against the same objects to verify the flow.
Before you start recording your QTP script, you need to identify the TEST STEPS that need to be automated.
There are many possible scenarios to test. In this Example, We will select a simple Test Scenario, to begin with. “Check that user successfully logs in to the application on inputting valid Agent Name & Password”
Here are the Test Steps for this Scenario
- Open Flight Reservation Application
- Enter Valid Agent Name
- Enter Valid Password
- Press Ok
- Close Application After Successful Login.
Let’s automate these 5 steps in OpenText Functional Testing (UFT One, formerly Micro Focus UFT and originally HP QTP). The video below runs through the whole session end to end.
Click here if the video is not accessible
Steps to Record a Script in QTP
Writing the steps down first matters more than it sounds: the recorder captures everything you do, so a wrong click becomes a step you have to delete later.
Step 1) In UFT One click the record button. The Record and Run settings Dialog Box Open. This box opens automatically each time you begin recording a new test
Step 2) Record & Run settings shows tabs corresponding to add-ins installed and loaded for your test. So, for example, if you have SAP Add-in Installed and loaded you will see an SAP tab. The Windows Application tab is always available and is used for environments, such as Visual Basic, ActiveX, and terminal emulators.
For any Environment, the Record and Run settings can be classified into two generic groups
1) Record & Run on ANY window belonging to that particular environment
2) Record & Run on a SPECIFIC window belonging to that particular environment – which is the recommended Option
For the time being, let’s stick to default settings. Once settings are done, UFT One remembers and uses the same settings for additional record sessions on the same test, unless you manually open the Record and Run Settings dialog box to modify the settings.
Step 3) Click okay. UFT One Starts Recording Mode
Step 4) Record the 5 test steps. In UFT One, Stop recording. Save the script as “LogIn”. Recording is done. More examples in the next tutorial.
While that session runs, two things happen behind the scenes. Each operation is added to the open action as a step, and each object you touch is added to the test’s local object repository with the properties UFT One will use to find it again. That is why the recorded script from these five steps reads as a plain hierarchy of Dialog, WinEdit and WinButton objects when you open it in the Expert View.
Record and Run Settings Explained
Step 2 above glosses over the dialog that causes most first-day confusion, so it is worth unpacking. The tabs you see depend entirely on which add-ins were loaded when UFT One started — load none and only the Windows Applications tab appears.
| Option | What it does | When to choose it |
| Record and run test on any open Windows-based application | Records operations on every Windows application with a user interface that is opened during the session, however it was launched. | Quick exploration, or when the application is started by another process you do not control. |
| Record and run only on (specific applications) | Restricts the session to the applications you nominate. | The recommended default. It keeps email clients and file managers out of the script and stops UFT One opening applications it does not need. |
Three practical points follow from that table. If you pick the “any open application” option, close the target applications first, because for some environments UFT One can only recognise applications opened after the option is confirmed. For web testing, the browser must be opened after UFT One itself. And although the dialog appears automatically only before the first recording session on a new test, it is worth reopening it through Record > Record And Run Settings before a run, since someone may have changed the target application since the script was recorded.
UFT One Recording Modes: Normal, Analog, Low-Level and Insight
The default mode handles ordinary controls, but a signature pad or an unsupported custom grid needs something else. Switch modes from the Recording Modes dropdown on the Record toolbar, and choose Default recording mode to return to normal.
| Mode | What it records | Use it when |
| Normal (default) | Objects and the operations performed on them, using the test object model. | Almost always. It recognises objects wherever they sit on screen. |
| Analog | Exact mouse and keyboard movement, relative to the screen or to one window. A single RunAnalog statement calls the recorded track. | Operations no object can express, such as a signature drawn with the mouse. The steps cannot be edited inside UFT One. |
| Low-level | Parent windows as Window objects and everything else as WinObject, with a small method set such as Click, DblClick, Drag, Drop and Type. | Unsupported environments where appearance may change but position will not, or where position itself matters. |
| Insight | Objects by their appearance rather than their native properties. | Controls UFT One cannot inspect at all, including a remote non-Windows desktop. |
| UI Automation | Objects in the application as UI Automation objects. | Applications exposed through the Microsoft UI Automation framework. |
Analog, low-level and Insight all consume more disk space than normal recording, and low-level steps do not always replay reliably on every object — treat them as targeted tools rather than defaults. A test that keeps needing them is usually a signal to write the steps with descriptive programming instead.
How to Play Back the Recorded Script
Recording only proves the steps can be captured. Playback is what proves they can be repeated.
- Confirm the Record and Run Settings still point at the application you want, then close the application so the first step opens it cleanly.
- Click Run. UFT One replays each step in order, matching every object against the properties stored in the object repository.
- Read the run results. A step that cannot find its object fails there, which tells you exactly which repository entry needs attention.
- Add checkpoints so playback verifies values rather than only completing without error.
A recorded script passes on the machine and data it was recorded with, and little else, which is the honest limitation of record and playback. Making it durable means replacing hard-coded values through parameterization, splitting the flow into reusable actions, and understanding how UFT One matches controls, covered in object identification. The full path from a recorded login to a maintainable suite is laid out across the UFT One tutorial series, and the replay walkthrough covers the run session in detail.
