Error Handling & Recovery Scenario

Recovery Scenario: When executing scripts we may get some Unexpected errors.To recover the test and continue running script from these unexpected errors we use Recovery Scenarios.

What happens in Recovery Scenarios? A recovery scenario consists of the following:

Trigger Event:

The event that interrupts your run session. For example a window that may pop up on screen.
Recovery Operations:

The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window.
Post-Recovery Test Run Option:

The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test. Recovery scenarios are saved in recovery scenario files having the extension .qrs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to our specific requirements.

Recovery scenario manger can handle following four events:

1. Pop-up window: To handle unwanted pop ups. 2. Object state: To handle object related errors at runtime. 3. Test run error: To handle vb script statement errors at runtime. 4. Application crash: To handle crashed applications at runtime.

1.Recovery Scenario for Popup Window: Steps to follow to handle unwanted popups: Trigger Event Steps: Resources Menu -->Recovery Scenario Manager -->New -->Next -->Select Popup Window as Trigger event -->Next -->Click on Hand Icon -->Show unwanted window with Hand icon ->Next -->Next -->(Continue below mentioned steps) Recovery Operations steps: Select function call as Recovery Operation -->Next {Open Notepad -->Save empty file with .vbs extension} -->Browse the .vbs fie path -->Next -->Uncheck Add another Recovery

Operation -->Next -->(Continue below mentioned steps) Post-Recovery Test Run Option Steps: Select Post-Recovery Test Run Option {Repeat current step and continue, Proceed to Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test run, Stop the Test Run} -->Next -->Enter Scenario Name -->Next -->Select Option --> Finish -->Save the scenario with .qrs -->Record required Recovery Operation {Click ok, Click Cancel} take the script into function -->Save the library file -->Click Run 2.Recovery Scenario for Object State: Steps to follow to check Property values of an object in the application match specified values. User can specify property values for each object in the hierarchy. Trigger Event steps: Resources Menu --> Recovery Scenario Manager --> New --> Next --> Select Object state Window as Trigger event --> Next --> Click on Hand Icon --> Show object with and icon --> Next --> Next-->select object property with value (enabled ,false)-->click next --> (Continue below mentioned steps) Recovery Operations steps: Select function call as Recovery Operation --> Next {Open Notepad --> Save empty file with .vbs extension} --> Browse the .vbs fie path --> Next --> Uncheck Add another Recovery Operation --> Next -->(Continue below mentioned steps) Post-Recovery Test Run Option Steps: Select Post-Recovery Test Run Option {Repeat current step and continue, Proceed to Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test run, Stop the Test Run} --> Next--> Enter Scenario Name --> Next --> Select Option -->Finish --> Save the scenario with .qrs --> Record required Recovery Operation {Click ok, Click Cancel} take the script into function --> Save the library file --> Click Run 3.Recovery Scenario for Test Run Error: Steps to follow to check if test does not run successfully then Test Run Error can be raised. Trigger Event steps: Resources Menu -->Recovery Scenario Manager -->New -->Next -->Select Testrunerror Window as Trigger event -->Next -->select any error o -->Next -->Next -->(Continue below mentioned steps) Recovery Operations steps: Select function call as Recovery Operation -->Next {Open Notepad -->Save empty file with .vbs extension} -->Browse the .vbs fie path -->Next -->Uncheck Add another Recovery Operation -->Next -->(Continue below mentioned steps)

Post-Recovery Test Run Option Steps: Select Post-Recovery Test Run Option {Repeat current step and continue, Proceed to Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test run, Stop the Test Run} -->Next >Enter Scenario Name >Next -->Select Option --> Finish >Save the scenario with .qrs -->Record required Recovery Operation {Click ok, Click Cancel} take the script into function -->Save the library file -->Click Run

4.Recovery Scenario for Application Crash: Steps to follow to check application failure during Test Run. Trigger Event steps: Resources Menu --> Recovery Scenario Manager--> Click New--> Click Next -->Select Application Crash as Trigger event-->Next -->Select selected executable application-->Next --> (Continue below mentioned steps) Recovery Operations and Post-Recovery Test Run Option Steps: Select Recovery Operation {Keyboard, Mouse Operation,Close Application Process, function Call, Restart, Microsoft Windows} -->Next -->If you want to check Add another operation else uncheck-->Next -->Next -->Enter Scenario Name -->Next-->Select Option -->Finish -->Close -->Save the scenario with .qrs

When to use Error handling(on error resume next) vs Recovery Scenarios ? If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or "on error resume next", rather than depending on a recovery scenario. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically. Example: A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.You cannot handle this error directly in your test, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test may have progressed several steps before the error is displayed. Therefore, for this type of event,only a recovery scenario can handle it. On error Statements Following are error statements :

1. On Error Resume Next 2. On Error Go to 0 3. err.number 4. err.description On Error Resume Next: On Error Resume Next statement enables the Error handling in the code.If there is error in the code "On error Resume Next" ignores it and continue with next line of code. On Error Go to 0: On error got to 0 statement disables error handling we have previiously enabled it by using On Error resume Next. err.number and err.description: Provides the error number and the description of the error Example:

'Call the function to divide call division Function division() on error resume next 'divide by zero z=40/0 ' Report the error occured. You can see the error number and description in result summary If Err.number <> 0 then Reporter.ReportEvent micWarning,"Error Occured","Error number is " & err.number & " and description is : " & err.description 'disables error handling on error goto 0 End if End function

What are Recovery Scenarios? While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To recover the test (and continue running) from these unexpected errors you use Recovery Scenarios. Next question arises,

When to use on error resume next or programmatic handling of errors VS Recovery Scenarios ? If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or on error resume next, rather than depending on a recovery scenario. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically. For Example: A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box. You cannot handle this error directly in your test or component, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test or component by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test or component may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it. I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional Users Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios > What constitute Recovery Scenarios? A recovery scenario consists of the following:

Trigger Event. The event that interrupts your run session. For example, a window that may pop up on screen, or a QTP run error. Recovery Operations. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows.

Post-Recovery Test Run Option. The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue, if at all. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test.

Recovery scenarios are saved in recovery scenario files having the extension .rs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements. Is there a method to programmatically call them? By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery objects method to force QTP to check for triggers after a specific step in the run session. For a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object

QTP Recovery Scenario Function Call

Recovery Scenarios
Automated tests are created mainly to be run unattended, and this raises a few concerns for automation developers. Assume a situation where you initiated your test-suite while leaving your office to be run over-night. However, because of unforeseen errors, your test stops at a point and disrupts your results. This is what brings us to creating Recovery Scenarios in QTP. For demonstration, a Test Run Error for item in list or menu not found is used.

This article discusses a way of creating a Recovery Scenario for an instance where an item in the list item or menu is not found.

In this example, we will define a Function Call and use that Function Call to handle the error. The default syntax for the Recovery Scenario Function is:

Function fnRecovery(Object, Method, Arguments, retVal) 'Error Handling Code End Function

Explanation of each argument to fnRecovery is given below:

Object as Object: The object of the current step. Method as String: The method of the current step. Arguments as Array: The actual method's arguments. Result as Integer: The actual method's result.

To handle this scenario, we will use the function below:

Function Recovery_ListItemIsNotFound(Object, Method, Arguments, retVal) Dim sAllItems, arrAllItems, intItem

With Object 'Retrieve all items from the Listbox sAllItems = .GetROProperty("all items") 'Split 'all items' using a delimiter ";" into an array arrAllItems = Split(sAllItems, ";")

'Select a random number intItem = RandomNumber.Value(LBound(arrAllItems), UBound(arrAllItems)) .Select "#" & intItem

Reporter.ReportEvent micInfo, "ListItemIsNotFound", "Item: " & .GetROProperty("value") End With End Function

Recovery_ListItemIsNotFound, as the same suggests, executes the Recovery Operation if the list item that we supplied to our target WebList does not exist. This is quite common in Web applications, and Items in a WebList can change depending upon the input(s) provided. To start, Click Resources -> Recovery Scenario Manager. You should see a window like this:

Recovery Scenario Wizard

In the window, click the following button:

Doing so will invoke the Recovery Scenario Wizard:

Recovery Scenario Wizard - Welcome

When the window above opens: 1. 2. Click Next Select Test Run Error as the Trigger Event

3.

Click Next

4.

Select Test Run Error: Item in list or menu not found in the Error Listbox

5.

Click Next twice and navigate to Recovery Operation

6.

Select Function Call and Click Next

7.

Select a library which will store our Recovery Function.

8.

Select Define New Function and in the TextArea, paste the function Recovery_ListItemIsNotFound

Define New Function

9. Click Next 10. Make sure Add Another Recovery Scenario Checkbox is not selected and click Next again.

11. Under Post-Recovery Test Run Options, select proceed to next step.

12. Give your scenario a name and Click Next

13. And finally, Check the following option: Add Scenario to current test and Click Finish. Save Changes before closing. We will use the WebList below to select a value that does not exist in it; so, lets write a code to select Rational Robot. If you view the items present in the listbox, you will notice that Rational Robot indeed doesnt exist, but our Recovery Scenario will handle the error when we select it. Instead, it will select a random value from the list.

Browser("title:=.*Recovery Scenario.*").Page("micclass:=Page")_ .WebList("name:=testTools").Select "Rational Robot"

MsgBox "Item Selected: " & Browser("title:=.*Recovery Scenario.*").Page("micclass:=Page")_ .WebList("name:=testTools").GetROProperty("value")

When the code above executes, you will notice that, instead of throwing a Test Run Error, a random value from the list box was selected. You will know that the Recovery Scenario was triggered and ran successfully when you view the Test Results:

Recovery Scenario Executed

There are plenty of other scenarios as well, and I will try to cover some of the important ones. If you have any suggestions, or a scenario that you would like me to cover first, please use the comments section of this post to share your ideas/thoughts with me. Thanks! :)

All about Recovery Scenarios using QTP

While executing scripts, we usually encounter unexpected & unpredictable events & errors, which results into application crashing during a run session causing total disruption of the run session and distortion of results. Such problems are quite frequent especially when the tests are made to run unattended. In such a case the test process halts until the user perform some desired recovery operation.
Recovery scenarios are useful when it is difficult to predict at which step the errors can come or when we are confident that the error will not come in the QTP script, whereas it can be anywhere outside the QTP Script. For illustration; Pop-up message of "out of paper", as caused by the printer device driver. "On error resume next" is preferred when we sure that the error is expected one and wish to perform some other actions. In order to handle such situations QTP comes to our rescue by creating recovery scenarios and associates them with the particular tests. What does a Recovery Scenarios do is to activate a specific recovery operation when a trigger events takes place. Most simple example of a typical unexpected & unpredictable events & errors is like Incompatible Media in portable Drive.

The Recovery Scenario Manager presents a structured wizard which helps us in defining the recovery scenario, like detailed definition of the unexpected event and the operations required to recover from the exception during the run session. Advantages of Recovery Scenario Manager: Recovery Scenario Manager can be used to handle several known errors occurring at runtime. Following four events available in the recovery scenario manager are extremely helpful 1) Application Crash: This event is useful in handling crashed applications at runtime.

2) Pop Up Window: This event is useful in managing various unwanted application windows, which get built-up at runtime. 3) Test Run Error: This event is useful in handling VBScript statement errors at runtime. 4) Object State: This event is useful in handling object related errors at runtime. Elements of Recovery Scenario: Steps to handle the exceptions are 1) Trigger Event: Is an unexpected event like appearance of a Pop-up window, object state, test run error causing application crash or interruption in our running session. 2) Recovery Steps: Constitutes a series of steps required to be performed to enable QTP to proceed further with the process of test after some trigger event has interrupted the run session. Examples of a recovery operation can be 1) A keyboard or mouse Operation like a Click over the "OK" button in the Pop-up window 2) Close Application Process 3) Function Call 4) Restarting the OS etc. 3) Post-Recovery Test Run: Are a set of instructions designed to be provided to QTP on proceeding further with the test after some recovery operation has been carried out. Examples of Post Recovery actions can be repeating the complete test from the beginning or some steps may be skipped altogether & continuing with the remaining steps in the test. QTP & Recovery Scenarios: All Recovery scenarios get saved & logically grouped in recovery scenario files. Grouping of various recovery scenarios in recovery scenario file can be managed according the user requirements. Recovery scenario files carry a typical extension of .rs. In order to instruct QTP to carry out a recovery scenario during a particular test run, we firstly associate it with the particular test. There is no limitation to any fixed number of recovery scenarios associated with a test. Order of execution of various recovery scenarios associated with a test can easily be prioritized, thereby the trigger events get recognized and handled in the desired sequence. Whenever any error comes during the execution of a test having many recovery scenarios associated with it; QTP intelligently hunts for the defined trigger event which had caused the particular error. After detecting the trigger event, QTP automatically performs the desired recovery steps and post-recovery test runs etc. Recovery statements can be inserted in the tests to comfortably control and activate the recovery scenarios during the test run. Cons of Recovery Scenarios: Although Recovery Scenarios are users friendly on one hand; they tend to slow down the speed of the Test Run. Presence of a few such recovery scenarios would reduce the speed of Test Run significantly. This can become irritant to the testers, who can prefer the approach of using VBScript On Error/Goto 0 far more useful for catching & handling small errors.