Run time Debugging through Print utility statement in QTP

I believe you have used "msgbox" function almost every time for debugging purposes i.e. displaying some text at run time. But the problem with "msgbox" function is that it keeps open till you close it and moreover you can’t debug further, since it’s a modal dialog box. You have to press OK button to move ahead.

How about a similar utility function, which works very similar, like "msgbox" and also provides the user the flexibility to perform further debugging?

Yes, it is possible. HP Quicktest Professional (QTP) provides a Print utility statement which is used to display information in the "QuickTest Print Log" window while still continuing your Run Session.

Looks pretty interesting!!!!!!! Alright, then go ahead and read more.

Firstly let us see what happens in case of "msgbox" function. As soon as the script encounters the "msgbox" function, it displays a dialog box and the script gets paused till the user presses the OK button.

Following screenshot demonstrate the concept.

Here you need to press the OK button in order to continue.

In order to counter this problem, HP QTP also provides a fantastic Print utility which is very similar to its "msgbox" counterpart but much more flexible. It can be used for debugging purposes. It is very simple to use inside QTP tool.

Following screenshot demonstrate the concept.


As you can see from this screenshot, QuickTest Print Log window remains open even after your script has finished running, thus providing more flexibility.

So from now on which one you would like to use? QTP’s "msgbox" function or QTP’s Print Utility Statement?

Did you like my explanation of the concept in the above article?

Being Technology Savvy, I am sure you must be curious to read many more interesting articles on QTP; How about subscribing to my Feed? This will help you in automatically knowing the moment I post an article on my Site.

So let us join and let us Learn & Master the great Tool QTP.

Keywords: HP QTP, Quicktest Professional, QTP Blog, QTP msgbox function, QTP Print utility statement

Read more...

Ways to manipulate conventional logic of naming objects in QTP

Here I am presenting a workaround to manipulate or overriding the Naming Conventions generally assigned by QTP to the test objects.

Did you ever notice that QTP gives a random name to the objects after recording which even seems vague at times.

Let me show you an example to demonstrate my point. I tried recording on the Google home page and got this code from QTP after recording after writing some text in the Google search box:

Browser("Google").Page("Google").WebEdit("q").Set "This is the sample text"

As you can see from the above code, the name which has been assigned to the WebEdit box is "q". How many of you agree that this "q" seems a valid name? Though this "q" is the name of the search box which has been hard coded by the Google developers. I have extracted the following code from the Google’s webpage to illustrate my point:

input maxlength=2048 name=q size=55 title="Google Search" value=""

I believe that QTP doesn’t name the test objects properly. There is certainly a way by which we can instruct QTP to name the text objects as per our chosen properties.

The following are the steps for the same:

1. Close your HP QTP software.

2. Navigate to Start->Run.

3. Type "regedit" and press enter to open the Registry Editor.

4. Inside your "Registry Editor" navigate to HKEY_CURRENT_USER -> Software -> Mercury Interactive -> QuickTest Professional -> MicTest -> Test Objects.

Here, you can see so many keys like WebEdit, WebElement etc etc. Yes, you guessed right. These are in fact all the built-in keys classes of QTP. Expand any key of your choice for editing.

In this tutorial, I will select WebEdit class which is very frequently used in QTP. You will see a key named "tag query name" as highlighted in the following screenshot which has the value "logical name". You will see the same value for "tag query name" key for all the inbuilt classes.



Now double click the "tag query name" key. You will see the following screenshot. Provide any name of your choice. I provided "QTP Expert" and press enter.




Close the Registry Editor and open your HP Quicktest Professional (QTP) software. Open google.com webpage again and record again. [ Make sure you open the google webpage only after opening QTP]. You will see a code something like this:

Browser("Google").Page("Google").WebEdit("WebEdit").Set "This is the sample text "

I hope, you must have noticed the difference after tweaking the registry editor.

This technique doesn’t seem to be used too often, however it is possible to override the standard naming convention of objects through QTP by doing some minor changes in Registry Editor.

KeyWords: QTP, Quicktest, Object Naming



Read more...

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



Read more...