Recovery scenario manager is used to handle unexpected events/errors during the execution of QTP script.
This is the general definition which we are seeing for a long time. But the question that arises is when should we use Recovery scenario manager and when not? And why is recovery scenario manager not used for all the events that gets raised while QTP execution?
Recovery scenarios are used only when the event occurrence is not predictable. That is if we are not sure at what place the event may get raised, then we go for recovery scenarios. If the event occurrence is predictable, then it is always recommended to use programmatic handling by using statements such as IF conditions or On error resume next. Because using Recovery scenario manager will slower down the performance of QTP.
For example, assume that Ads are getting raised when Application is opened in a browser or while accessing the application. Assume that sometimes they get raised immediately as soon as you open a browser and sometimes they get raised only after you are accessing something on the page. And also assume that you are not able to predict how many ads get displayed. In such situations we go for Recovery Scenarios.
One of the other best example and common example is Printer out of Paper example. It is not possible to predict at what time Network would return the printer error. Hence Recovery scenario is used in this example because by the time the printer error message gets raised QTP might have progressed several steps before the error is displayed.
For example, assume that Ads are getting raised when Application is opened in a browser or while accessing the application. Assume that sometimes they get raised immediately as soon as you open a browser and sometimes they get raised only after you are accessing something on the page. And also assume that you are not able to predict how many ads get displayed. In such situations we go for Recovery Scenarios.
One of the other best example and common example is Printer out of Paper example. It is not possible to predict at what time Network would return the printer error. Hence Recovery scenario is used in this example because by the time the printer error message gets raised QTP might have progressed several steps before the error is displayed.
Some of the examples where we don’t go for Recovery scenarios:
The dialog box that gets prompted for remembering the password. This can be handled using If statements.
The dialog box that gets raised to overwrite the existing file during the process of saving a file.
How to create a Recovery Scenario:
Select Recovery Scenario Manager from Resources>>Recovery Scenario Manager.
Click on New to create a new Recovery Scenario and it takes the user to ‘Recovery Scenario Wizard’.
Recovery Scenario involves following steps:
1. Define the trigger event that interrupts the test run
Define the trigger event that interrupts the test run such as Popup window, QTP error or Application error.
1. Define the trigger event that interrupts the test run
Define the trigger event that interrupts the test run such as Popup window, QTP error or Application error.
2. Specify the recovery operation(s) required to continue
Specify the recovery operations that need to be performed on the trigger event such as closing the Popup through keyboard operation/mouse operation, closing the application, Calling a function or restarting windows.
3. Choose a post-recovery test run operation
Instructing QTP what should be done after performing the recovery operations on Triggered event. For example like re-executing the same step in the test or moving to next step in the test or moving to the next test or close the execution of qtp script etc.,
Specify the name and description for the recover scenario.
Specify whether to add the recovery scenario to current test or make it a default to all the new tests that are created here after.
Reference: Quick Test User guide - Defining Recovery Scenarios