How to use Recovery Scenario in QTP/UFT with Example

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Recovery scenarios instruct UFT One to detect an unexpected event during a run session, perform a corrective operation, and then continue the test automatically instead of pausing an unattended run until somebody intervenes.

  • 🔘 Definition: A recovery scenario pairs a trigger event with a recovery operation and a post-recovery instruction.
  • ☑️ Where it lives: The Recovery Scenario Manager wizard under the Resources menu creates and stores every scenario.
  • ✅ Trigger events: Pop-up window, object state, test run error and application crash are the four supported types.
  • 🧪 Recovery operations: Keyboard or mouse action, close process, function call and restart Windows.
  • 🛠️ Post-recovery: Six options decide whether the run repeats, skips, restarts or stops after recovery.
  • ⚠️ Alternative: On Error Resume Next handles predictable VBScript errors inside a single step.
Read More

How to use Recovery Scenario in QTP UFT with example

Using Recovery Scenarios you can instruct UFT One to recover from unexpected events and errors that occur in your Testing environment during a run session.

Recovery scenario becomes crucial for large tests, which run unattended and are paused until a recovery operation is performed, increasing the test execution time.

⚠️ Product naming: the tool in this guide shipped as HP QuickTest Professional (QTP), became HP Unified Functional Testing, then Micro Focus UFT One, and is now sold by OpenText. The menu paths below are unchanged, so the steps still apply.

Steps to use Recovery Scenario in QTP/UFT

There are 6 steps involved in creating a recovery scenario

Step 1) In UFT One, Select Resources > Recovery Scenario Manager. Create new Scenario

Step 2) Specify the Trigger Event. A Trigger Event is an event that interrupts your run session

Step 3) Specify the Recovery Operation which is the corrective action you take when the trigger happens

Step 4) Specify Post-recovery test run options which specify how to continue the run session after Quick Test Professional has identified the event and performed all of the specified recovery operations.

Step 5) Check and verify Summary of the scenario you created.

Step 6) Add Recovery Scenario to your test using File > Settings > Recovery. The test results window show the details of the recovery scenario

Following video explains the steps in detail

Click here if the video is not accessible

Note: the wizard does not fire for a trigger that occurs in the very last step of a test. Add a spare step at the end when the final action can fail.

Trigger Events Supported by UFT One

Step 2 above asks for a trigger event, and the wizard offers exactly four kinds. Choosing the right one matters, because each type recognises the interruption in a different way.

Trigger event How UFT One recognises it Typical example
Pop-up window Window title and the text inside the window A “printer out of paper” message box
Object state Property values of the object and of all its ancestors A button that is disabled while another process is open
Test run error A failed return value from a method A menu item that is missing at that point in the run
Application crash A predefined list of applications A secondary application that closes mid-run

An object state trigger is matched per object, so if two objects reach the same state the recovery operations run twice, once for each match.

Recovery Operations and Post-Recovery Run Options

Steps 3 and 4 define what happens once the trigger fires. The recovery operation is the corrective action, and UFT One supports four of them.

  • Keyboard or mouse operation — click a named button in the window or send a key combination.
  • Close application process — pick one or more running processes from the list and end them.
  • Function call — run a VBScript function stored in an associated function library.
  • Restart Microsoft Windows — the heaviest option, reserved for an unrecoverable environment.

Several operations can be queued in one scenario, and they execute in the order listed. The post-recovery option then tells the run session where to resume.

  • Repeat current step and continue
  • Proceed to next step
  • Proceed to next action iteration
  • Proceed to next test iteration
  • Restart current test run
  • Stop the test run

Pick Repeat current step when the pop-up simply blocked a click, and Proceed to next test iteration when the data row itself is the problem. A scenario saved through the wizard is stored in a .qrs file, so several tests can share it, and the order of scenarios attached to a test decides which one is applied first.

RELATED ARTICLES

Handling Errors with On Error Resume Next

A recovery scenario answers an event nobody predicted. A predictable failure — a missing file, a value that fails to set — is cheaper to trap inside the script itself with VBScript error handling.

Use can also use statements

  • On Error Resume Next : execution continues on the next line instead of stopping, and the failure is recorded in the Err object.
  • On Error GoTo 0 : the default behaviour returns, so any later error stops the run again.

to handle errors in your script

The two statements work as a pair. Open the guarded region, check Err.Number straight after the risky line, report the result, clear the object, then close the region.

On Error Resume Next

SystemUtil.Run "notepad.exe"

If Err.Number <> 0 Then
    Reporter.ReportEvent micWarning, "Launch application", Err.Description
    Err.Clear
End If

On Error GoTo 0

Note: VBScript has no On Error GoTo <label>. Only Resume Next and GoTo 0 are valid, and the setting applies to the current procedure only.

Situation Better choice
Random pop-up or application crash Recovery scenario
A single step that may legitimately fail On Error Resume Next
Unattended overnight suite Recovery scenario, so the run never waits
Validation that must be reported per step On Error Resume Next with Reporter.ReportEvent

FAQs

The wizard saves each scenario in a shared recovery file with a .qrs extension. Because the file sits outside the test, several tests can associate the same scenario instead of each defining its own copy.

Check three things: the scenario is associated with the test in the Recovery pane of Test Settings, the check box beside it is enabled, and the trigger is not in the final step, which the recovery mechanism does not monitor.

Yes. UFT One applies scenarios in the listed order and stops at the first match, so move the most specific scenario to the top and leave broad catch-all scenarios at the bottom.

The activation setting decides: on every step, on an error only, or never. Checking on every step is the safest and the slowest, so reserve it for suites where stability matters more than run time.

It resets Err.Number to zero and empties the description. Without it the previous failure stays in the object, and the next check reports an error that already happened.

Machine learning over historical run logs clusters repeated interruptions by window title and error code, which shows the recurring pop-ups worth automating and separates them from one-off environment noise.

Yes. GitHub Copilot drafts the Err handling and the recovery function body from a comment, but verify the UFT One object names, because the model often suggests VBA syntax instead.

Yes, when the application is unusable. Choosing Stop the test run prevents dozens of cascading false failures, and the results window still records the trigger that caused it.

Summarize this post with: