Application of Fault Tolerance Approach using QTP

Let us try to understand this concept of fault tolerance a bit Step-by-step.

What is a Fault Tolerant System?
When any system is able to recover from some unexpected errors and is able to restore the normal operation, it is known as a Fault Tolerant system.

When do we need a fully Fault Tolerant System?
Since it is a very complex & costly process to ensure perfect error recovery in a fault tolerant systems, this approach is deployed in applications where safety, availability and time requirements are of prime importance.

Why there is a need to tackle the Errors?
Only the single major characteristic i.e. Reliability identifies any high-quality software. A good piece of software must be able to behave as expected in almost all situations. Although software development companies, during the process of development, try their best to avoid, detect and remove maximum umber of errors as possible, still they can’t take it for granted that the delivered software is free of errors. Due to this there comes the need to have adequate mechanism in place, which could protect the productive system from unacceptable behavior in case of error like situations.

How to handle the situation in case of an error?
When an error occurs primarily due to some faulty design and we are not able to rectify the fault on-line, and we can not afford to move ahead with inconsistent or corrupted data. In such situation it is best to terminate the application in a controlled way (of course whenever possible) rather than trying to do recovery from the error to continue the normal operation.

Usually a script designed for testing an application remains in a Technically Feasible / Good State, during the normal operation. However Good States always have their evil counterparts as well i.e. the Bad States. And the creator of the scripts would never like his script to land into such Bad States. But a patient tester keeps him mentally prepared for his script landing into a Bad State & he tries to minimize such problematic by anticipating such problem situations and ably converts them into expected situations for his benefit.

What should be the realistic approach?
The best approach in business information systems is generally aimed at pumping maximum resources of time, money & efforts in prevention of errors during the development and creation of robust system. This would ensure correctness and integrity of the data and will go even one-step further in prevent any corruption and loss of the data.

Understanding Error-handling Mechanism of a Test Tool:
Almost each & every test tool addresses following elements of its error handling mechanism:

1) Fault: It is the origin of any misbehavior. It is the byproduct or the cause of an error.

2) Error: It is a part of a system state, which leads to a failure. User errors don’t become a part of this definition, since user errors are mistakes committed by the user while operating a software system.

3) Detector: An error needs to be detected first before the tool can act on it. The error handling mechanisms in a tool interacts with errors and failures of the application. Thus a detector is an interface between the error and failures taking place in the system.

4) Failure: It is a deviation of the delivered application in its compliance with the basic specifications. It differs from error in way that the error refers to a particular state of a system, whereas a failure is a specific event, which is basically a transition from the correct delivery to the incorrect delivery.

5) Exception: It is an abnormal condition, which interrupts the normal control flow. To raise an exception, a program needs to detect an error or failure first.

A typical relationship among above-mentioned elements of error handling mechanism are explained pictorially as under.


QTP & its error handling potentials:
QTP along with its prime companion VBScript (if designed with care & consideration) are quite powerful in handling errors and Exceptions. Design & developments of QTP scripts is an art, but not too difficult to learn & master.


As said earlier, design of good script for QTP is extremely important, so that the script behaves well in almost every situation and it should be able to handle not only with the normal situations but also many unexpected situations.

While designing scripts for QTP, the script designer must keep the underlying motto at the back of his mind and that is "Expect the Unexpected". Development of QTP scripts is thus treated almost similar to the development of any other software package & I feel that both of these need to be treated the same way.

Attributes of a strong error handling system:Robust scripts capable of tackling problematic states are designed to operate under architecture, equipped with error handling facilities like:

1) Ability to detect errors.
2) Ability to handle errors.
3) Transmission of error related information among all concerned
4) Management of important information for analyzing & resolving the errors.
5) Management of error messages for reporting to the user or the testers.

Error handling mechanisms of QTP:
During the run session, if an error occurs in QTP the script is halted & the error handling mechanism of QTP releases a popup message box describing the error to the user informing of the problem. The user is prompted to select an option of clicking a button on this message box to either continue to execute the program or end the run session. The error message can accompany a screenshot / bitmap capture of the error event for better clarity.

The tester has option to accept the Popup Message Box option or he can specify a different response by choosing one of the alternative options in the list in the "When error occurs during run session" box:

a) Proceed to next action iteration – QTP proceeds to the next action iteration when an error occurs.

b) Stop run – QTP stops the run session when an error occurs.

c) Proceed to next step - QTP proceeds to the next step in the test when an error occurs.

QTP first performs the particular recovery scenarios associated with the test, and performs the option selected above only if the associated recovery scenarios are not able to resolve the error.


Programmatically Controlling the Recovery Mechanism in QTP:
Recovery object can be used to control the recovery mechanism programmatically during the run session. For example, the entire recovery mechanism or particular recovery scenarios can be enabled or disabled. The status information related to the particular recovery scenarios can be retrieved and the recovery mechanism at a certain point in the run session can be activated.


By default, QTP checks for recovery triggers when an error is returned during the run session. We can use the Recovery object's Activate method to force QTP to check for triggers after a specific step in the run session. For example, when we are aware of the fact that an object property checkpoint will fail if certain processes are open when the checkpoint is performed. We want to be sure that these open processes, which may indicate a different problem with the application, do not affect the pass or fail of the checkpoint.

However, a failed checkpoint does not result in a run error. Hence by default, the recovery mechanism would not be activated by the Object State. We can define a recovery scenario, which looks for, and closes specified open processes when an object's properties have a certain state. This state shows the object's property values, as they would be if the problematic processes were open. We can instruct QTP to activate the recovery mechanism if the checkpoint fails so that QTP will check for and close any problematic open processes and then try to perform the checkpoint again. This ensures that when the checkpoint is performed the second time the open processes do not affect it.

Use of Check Points in QTP:
As said earlier that prevention is better than cure, QTP provides a very powerful tool of using Checkpoints to check various objects in the application to ensure that they function properly.

Checkpoint is nothing but a point of verification, which compares a current value for a specified property with the expected value for that property. This enables the tester to identify whether the application is functioning correctly or not. When the test is run, QTP compares the expected results of the checkpoint with the current results. If the results do not match, the checkpoint fails & the end result gets displayed in the result window.

QTP provides eleven types of checkpoints to the testers. The details of each & every Checkpoint are not included in this article.

Use of Synchronization Points in QTP:
As an alternative to create a checkpoint or perform a step until the application object aquires a particular status, a synchronization point can be inserted to instruct QTP to halt the testing process till the object property reaches a value specified by us (or till a timeout specified by us has exceeded).

If we don’t have a synchronization point, QTP is likely to click the Update Order button too quickly during the test execution process, which will result in failure of the test.

Finally - Understanding of the Best Practices:

1) A best method to use error-handling mechanism is to try to prevent the errors. Whenever an error happens, try to capture the maximum related information & report it in detail.

2) Perform a syntax check every time the script is changed.


Key Words : QTP, Error Handling, Recovery Scenario, Synchronization, Check Point, Recovery Mechanism