This is the 6th QTP Tutorial in our QTP training series. 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 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 a few ways in which our tests can be tailored to meet our needs.
Hence, I think we are ready to record our first test in its entirety.
We are just going to do 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.
What You Will Learn:
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 the “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.
Given below is 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 only available when the web add-in is selected to be loaded at a startup. 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 if a Siebel add-in is installed and loaded during startup.
Let’s look at the ‘Web’ tab first”.
“Web Tab” On Record and Run Settings Dialog
The default settings are as shown in the above picture. This setting means that when a record session has started, the target of the record operation can be any of the web applications that are already open in a browser.
The user also has an instruct QTP to ignore certain web pages like QC or any other page with a specific URL or a specific title. The user can navigate to “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” then the corresponding elements in the screen get enabled.
Take a look at it below:
The user can enter the address of any page and choose their browser. The browsers that QTP 11 supports are given below.
Only the browsers that are supported and are currently installed on your machine will appear on 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 have not yet gotten 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 will be dealt with later.
“Do not record and run on browsers that are already open” – If this option is chosen, then all the browsers that are open prior to recording and running and 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 on 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 browser 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 Windows-based applications. The default option is to record and run on any Windows app that is open.
If the “Record and Run only on” option is chosen, the other options under it get activated.
- 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.
- Applications opened via Desktop (by Windows Shell): This means that the application that is opened from a windows desktop is chosen.
- 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 with 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 the 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 settings in the Windows tab do not directly affect the testing performed on the 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 the “RUN” option from QTP. The Run operation too invokes the application (web or windows) depending on the setting specified.
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 a few things as needed.
We will discuss these checkpoints in the upcoming series of articles and also try to learn the best practices to be followed during test creation to ensure maximum efficiency.
Feel free to post your QTP questions on this or previously covered QTP tutorials in the comments below. If you have any suggestions for improving these tutorials, then please contact us.