QTP Tutorial #15 – Using Text Area, Table, and Page Checkpoints in QTP

In the last article, we were discussing the ways in which QTP can compare text.

We also saw how standard checkpoints can be used to check the text and discussed the text checkpoint in detail. The next checkpoint is the Text area checkpoint. Let’s begin exploring it.

=> Click Here For The QTP Training Tutorials Series

Text Area Checkpoint

• This is used for windows applications.
• Compares a text string within a defined area according to the criteria specified.
• Defining the properties for this checkpoint is almost the same as that for a text checkpoint.
• The only dominant difference between Text checkpoint and Text Area checkpoints apart from the environments is that text checkpoint works on a certain object and text area works on a region selected.
• Though the menu option for text area checkpoints is available even while recording a web app when chosen, it is going to throw you an error that the web environment is unsupported for this checkpoint.

Table Checkpoint

• It can be used in cases when you need to verify that a particular cell in a table has a certain value or in some cases if the table itself has the defined number of rows of columns.
• When a web table or an equivalent table object is chosen to insert a checkpoint on, the Table checkpoint properties get invoked.
• As a menu option, you choose “Standard Checkpoint” while recording. So the ground rules like creation, editing, and maintaining are all the same.

Let us look at an example:

I will pick a random site that has a web table. Open Internet Explorer. Start recording, Insert checkpoint -> Standard checkpoint, and choose the table object in the web page.

Select the Web Table element and click OK.

In the properties window, select the cell and specify if a constant value has to be there or parameterized.

The settings tab will show the way in which the verification has to be carried out.

Cell identification: This tab is where the user has the settings to identify a particular row or column.

As explained earlier, since this is a variation of the standard checkpoint all the same rules apply.

• Although this inbuilt feature is available for checking tables, I don’t find it very useful. There are other functions like GetRowCount, GetColumnCount, GetRowItem, etc. to verify the tables. Let me explain that a little bit more before we move on.

• In practical scenarios, checking just one cell might not suffice, and creating a single checkpoint for each value in the table might get cumbersome. For Example, If a table is 3X3 then to check each cell, we will see 9 checkpoints. If the value in the second or first cell itself does not match, it does not signal an inconsistent table which defeats the purpose and results in the unnecessary continuation of checking the other cells.

• Instead, by reading the table and using GetRowCount, GetColumnCount, and GetRowItem functions, you can establish a looping mechanism and check as needed, and exit on failure. The only consideration for a tester at this point would be to make sure that he writes appropriate test results so that there is clarity.

• Also, table checkpoint fails in the case of dynamic tables.

Page Checkpoint

Page checkpoint is another variation of a standard checkpoint, which as the name indicates comes up when created on a Web Page.

It can be used for the following:

• Checking links
• Sources of images
• Check for broken links

Let us place one and see how it works and what it can do as we proceed.

Open Google.com in internet explorer or any browser compatible with the current version of QTP you have on your machine. Record a new test in QTP, Select “Insert Checkpoint -> Standard checkpoint” and point it to the google.com page. Then, select the “Web Page” object from the object list displayed.

The following dialog gets displayed:

As you can see, the parameters that can be checked are in the list and proceeded with a checkbox with a check option. Users can choose any number of properties as required.

As this is the case with all the other checkpoints we have seen so far, each of these properties can be a constant value or the user can parameterize.

The next section is HTML verification:

• HTML Source: Checks if the HTML code for the web page matches the actual one at runtime. The user has the option to modify it as required while creating a checkpoint and check if it matches at the run time.
• HTML Tags: Checks the HTML tags for the web page at the record and run times. As with HTML sources, HTML tags can be modified too.

‘All Objects in the page’ Section:

#1) Links: On checking this, all the links are verified. To check only certain links the “Filter Link Check” can be clicked and the following dialog appears:

You can select the links or unselect them. The link URL value can again be a constant or a parameterized value.

#2) Images: Checking this ON means that you can verify the presence of the images on the page at runtime.  On clicking “Filter Image Check” the user can select the exact images that are to be checked and the ones that have to be ignored.

The following tab gets displayed when the user chooses to Filter:

As usual, the user can configure the values.

#3) Broken Links: This option is not usually ON by default and upon checking it ON, it verifies if there are any broken links on the web page.

Users can check for broken links that are only on the same host as of the parent page. The relevant option has to be set in the following screen that can be launched by using the “Tools -> Options -> Web” menu option.

Once this checkpoint is run, all failures, if any, will be displayed in the Test Results. Otherwise, the checkpoint passes.

Some of the Page Checkpoint options are only available when the checkpoint is created during recording. If you try to create them from the Active screen or Keyword view, the HTML verification options won’t be available.

To summarize the page Checkpoint:

#1) Useful in the web add-in while checking pages. Checks for the integrity of the pages.

#2) A variation of a standard checkpoint, so all the rules of creation, editing, and maintaining are the same.

#3) QTP can be instructed to put a checkpoint on every page. This can be done by choosing “Tools -> Options -> Web -> Advanced” from the menu and clicking the option ON.

#4) Alternately, you can instruct QTP to bypass automatic checkpoints. Select the following option in the same window that we launch in point 3.

This leaves us with Accessibility, Database, and XML checkpoints which will be the topics for the next session. Please post your comments and questions below.

=> Visit Here For The QTP Training Tutorials Series