Recovery Scenarios in QTP

Recovery Scenarios in QTP

Recovery scenario - a definition of an unexpected event or error or application crash and the operation(s) necessary to recover the run session

A recovery scenario consists of the following:

a. Trigger Event—The event that interrupts your run session

b. Recovery Operation(s)—The operation(s) that need to be performed in order to continue running the test or component

c. Post-Recovery Test Run Option—The instructions on how Quick Test should proceed once the recovery operations have been performed, and from which point in the test or component Quick Test should continue, if at all.

Recommendations for using Recovery Scenarios

1. If you can predict that a certain event may happen at a specific point in your component, it is highly recommended to handle that event directly within your component by adding steps such as If statements or “Optional Steps” in user-defined functions, rather than depending on a recovery scenario.

2. You should use recovery scenarios only for unpredictable events, or events that you cannot synchronize with a specific step in your component.

3. Handling an event directly within your component enables you to handle errors more specifically than recovery scenarios. It also enables you to control the timing of the corrective operation with minimal resource usage and maximum performance.

Different Recovery Operations:

1. Keyboard or mouse operation—Quick Test simulates a click on a button in a window or a press of a keyboard key.

2. Close application process—Quick Test closes specified processes.

3. Restart Microsoft Windows—Quick Test restarts Microsoft Windows.

Note: If you use the Restart Microsoft Windows recovery operation, you must ensure that any component associated with this recovery scenario is saved before you run it. You must also configure the computer on which the component is run to automatically log in on restart.

4. Function call—Quick Test calls a VBScript function.

Note: User can select an existing function from a library file or he can define a new function. The new function is added to the function library you selected.

Different Post-Recovery Test Run Options:

1. Repeat current step and continue

The current step is the step that Quick Test was running when the recovery scenario was triggered.

Note: If you are using the On error activation option for recovery scenarios, the step that returns the error is often one or more steps later than the step that caused the trigger event to occur. Thus, in most cases, repeating the current step does not repeat the trigger event.

2. Proceed to next step

Skips the step that Quick Test was running when the recovery scenario was triggered.

Note: Keep in mind that skipping a step that performs operations on your application may cause subsequent steps to fail.

3. Restart current test run

Stops performing steps and re-runs the component from the beginning.

4. Stop the test run

Stops running the component.

Note: If you chose Restart Microsoft Windows as a recovery operation, you can choose from only the last two test run options listed above.

Associating Recovery Scenarios with the test:

a. While associating the recovery with your test, you need to specify when you want to activate recovery scenarios i.e. only on errors or on every steps.

b. If you select On errors option then keep in mind that by default, recovery operations will be activated only when a step returns an error, which can potentially occur several steps after the one that actually caused the error. So you may get the advantages of using recovery scenarios.

Note: If you are using “On Error Resume Next” statement in a script which has some activated Recovery scenarios then keep in mind that “On Error Resume Next” is NOT going to affect the triggering of Recovery Scenario i.e. Recovery Scenarios has priority over “On Error Resume Next”.

c. If you select on every steps then keep in mind that checking for trigger events after every step, may slow performance.

Note: In this case, use “Recovery Object” which enables you to control the recovery scenario mechanism programmatically during the run session. “Activate Method” is an useful method associated with Recovery Object which explicitly activates the recovery scenario mechanism at a specific point in the run. Activating recovery scenarios in particular section of the script, where the probability of unexpected event or error or application crash is high, can improve performance.

When To Use Recovery Scenarios

Recovery scenarios are intended for use only with events that you cannot predict in advance, or for events that you cannot otherwise synchronize with a specific step in your test. For example, you could define a recovery scenario to handle printer errors. Then if a printer error occurs during a run session, the recovery scenario could instruct QuickTest to click the default button in the Printer Error message box.

You would use a recovery scenario in this example because you cannot handle this type of error directly in your test. This is because you cannot know at what point the network will return the printer error. Even if you try to handle this event by adding an If statement in your test immediately after a step that sends a file to the printer, your test may progress several steps before the network returns the actual printer error.

If you can predict that a certain event may happen at a specific point in your test, it is highly recommended to handle that event directly within your test by adding steps such as If statements or optional steps, rather than depending on a recovery scenario. For example, if you know that an Overwrite File message box may open when a Save button is clicked during a run session, you can handle this event with an If statement that clicks OK if the message box opens or by adding an optional step that clicks OK in the message box.

Handling an event directly within your test enables you to handle errors more specifically than recovery scenarios, which by nature are designed to handle a more generic set of unpredictable events. It also enables you to control the timing of the corrective operation with minimal resource usage and maximum performance. By default, recovery scenario operations are activated only after a step returns an error. This can potentially occur several steps after the step that originally caused the error. The alternative, checking for trigger events after every step, may slow performance. For this reason, it is best to handle predictable errors directly in your test.