QTP Tutorial #6 – Understanding QTP Record and Run Settings for Our First Test

This is the 6th QTP Tutorial in our QTP training series. Please visit this post to check out list of all tutorials we covered till now. As a reminder, we have started the QTP online training article series and we’ll be covering almost all QTP tutorials with simple examples to understand the concept.

The last few QTP tutorials have been about the QTP’s Keyword view which was really crucial in getting a high-level understanding of a QTP test’s structure and also introduced us to few ways in which our tests can be tailored to meet our needs.  So I think we are ready to record our first test in its entirety.  We are going to do just that in the next few QTP training articles. Today’s topic, therefore is the first step in doing so which is the “Record and Run settings’. We are going to understand all about this, why it is important and how this can affect a test.

Record and Run Settings Dialog

When QTP is launched and we choose to record a new test, the ‘record and run settings’ dialog opens up.  Alternately a user can choose to access this window by choosing “Automation->Record and Run Settings” option from the menu. So far in our examples we have just continued with its default settings but now we will explore it further. The following is the how this dialog looks:

As the same suggests, this is a space that QTP provides the user to set certain parameters that help the user to create a test via record and to execute the same during a run session.
QTP can record and run a test on either a windows app or a web app. The web tab is available only when the Web add-in is selected to be loaded at start up. This tab is used for Web, .NET Web Forms, PeopleSoft, and Web-based SAP objects. So there are 2 tabs to define the settings separately for each of these environments.  There will be a separate ‘Siebel’ tab available is a Siebel add-in is installed and loaded during start up.
Let’s look at the ‘Web’ tab first”:

“Web Tab” on Record and Run Settings Dialog:

The default settings are as shown in the picture above. This setting means that when a record session is started the target of the record operation can be any of the web application that is already open in a browser.  The user also has a instruct QTP to ignore certain web pages like QC or any other page with a specific URL or a specific title. The way he can do that is, “Tools->Options->Web” and define those pages in the following QTP dialog:

But if the user chooses, the next option “Open the following address when a record or run session begins” the corresponding elements in the screen get enabled. Take a look at it below:

The user can enter the address of any page and the choice of the browser.  The browsers that QTP 11 supports are:

The browsers that are supported and are currently installed in your machine will only appear in the list.
There is another way to set the record and run settings other than from this window and that method is through Environment variables. Since we did not yet get there, we will discuss them in detail later on. For the sake of mentioning, if the environment variables URL_env and Browser_env are set, then it overrides the URL and browser chosen in the ‘Record and Run Setting’ window. How to create these and how they work – all this will be dealt with later.
‘Do not record and run on browsers that are already open ‘– If this option is chosen all the browsers that are open prior to recording and running and also prior to launching QTP will be ignored.  It is as if these browsers don’t exist for QTP because the user can not even spy these pages to view the objects. In other words, these browsers are totally ignored and as a result deemed inaccessible to QTP.

‘Close the browser when the test closes’ – this option when chosen will close the browsers on which the record and/or run session was carried out when the test ends.

“Windows Tab” on Record and Run Settings Dialog:

This tab is for the windows based applications. The default option to record and run on any windows app opened.

If the “Record and Run only on’ option is chosen, the other options under it get activated.

1. Applications opened by QuickTest: when this option is chosen, the applications that are opened as a result of an invoke operation performed by Quick Test are only chosen for recording
2. Applications opened via the Desktop (by the Windows shell): This means that the application that are opened from a windows desktop are chosen
3. Applications specified below: choosing this option will open another child window where a specific app to be opened by the QTP at the beginning of a record or run session can be defined.

As you can see from the above window, the path of an application and its folder should be added and QTP opens that particular app while record and/or run.
That concludes a quick introduction to various ‘record and run settings’ that can be used for a QTP test. When testing a web app, it is also important to make sure that we add the correct settings in the windows application tab too. It is crucial because, it will help us in preventing opening up of unnecessary applications and also to make sure that we do not accidentally change any of the already open windows applications. It should be noted that, the setting in the windows tab do not directly affect the testing performed on a web app.
So the recommended settings for the windows tab while testing a web app are:

Once these settings are done, the test recording begins. Any operation performed on the test gets recorded in the QTP. The tester can stop the record operation once all the steps that he wished to perform on the AUT are done by clicking on the “STOP” option available in the QTP menu.
The recorded steps can then be re-performed on the AUT by choosing ‘RUN’ option from QTP. Run operation too invokes the application (web or windows) depending on the setting specified.

Conclusion

This forms the basis for performing any basic steps on the AUT using QTP. In the real world this alone isn’t sufficient. Testing as an activity is verification and validation inclusive, so we will have to tailor these basic lines of code to include certain verification and validation points. To do so, QTP provides some checkpoints and the tester can also programmatically add steps to check few things as needed.
We will discuss these checkpoints in the coming series of articles and also try to learn the best practices to be followed while test creation to ensure maximum efficiency.
Feel free to post your QTP questions on this or previously covered QTP tutorials in below comments. If you have any suggestion for improving these tutorials please contact us.