When To Use Recovery Scenarios

Deciding 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.

For more information on optional steps, see Using Optional Steps. For more information on inserting programming statements such as If statements, see Adding Steps Containing Programming Logic.