QTP Tutorial #16 – Steps to Insert XML, Accessibility, and Database Checkpoints

Today we will continue with the remaining QTP checkpoints i.e XML, Accessibility, and Database Checkpoints. This is the last tutorial on QTP checkpoints. We have covered details of all QTP checkpoints in the last 4 tutorials.

=> Click Here For The QTP Training Tutorials Series

By adding XML checkpoints to your test, you can check the contents of individual XML data files or documents that are a part of your Web application.

XML Checkpoint

• You can perform checkpoints on XML documents contained in Web pages or frames, on XML files, and on test objects that support XML.
• An XML checkpoint is a verification point that compares a current value for a specified XML element, attribute and/or value with its expected value.
•  When you insert a checkpoint, QuickTest adds a checkpoint step in the Keyword View and adds a Check CheckPoint statement in the Expert View.
• When you run the test, QuickTest compares the expected results of the checkpoint to the current results. If the results do not match, the checkpoint fails.

You can create three types of XML Checkpoints:

• XML Web Page/Frame Checkpoint: Checks an XML document within a Web page or frame.
• XML File Checkpoint: Checks a specified XML file.
• XML Test Object Checkpoint: Checks the XML data for an object or operation.

The method to insert this checkpoint is almost similar to the other ones.

Step #1: While recording, select Insert -> Checkpoint -> XML checkpoint( from application) option

Step #2: Select the page where you want to insert the checkpoint.

Step #3: The following screen comes up:

Step #4: Set the values as desired on this screen and click OK

Step #5:

 Browser("Browser").Page("Page").WebXML("http://www.w3schools.com/xml/c").Check CheckPoint("http://www.w3schools.com/xml/cd_catalog.xml") 

– This statement gets inserted.

Alternately, if you need to insert an XML checkpoint on a file in your machine, you can choose the option:

“Insert -> Checkpoint -> XML checkpoint(from resource)” and select the XML file test object.

The steps that follow are similar to the ones above.

The option “XML checkpoint(from the application)” is available only when the web add-in is available and loaded for a certain test.

Accessibility Checkpoint

This checkpoint is supported only when the web add-in is available and loaded. It checks or recognizes if the areas on a website conform to WWW consortium Web accessibility guidelines.

It can be added while recording or editing through the active screen.

The properties that we can check based on the Accessibility Checkpoint are:

1. Active X check
2. Alt property check
3. Applet check
4. Frame titles check
5. Multimedia check
6. Server-side Image check
7. Tables check

The tester has the option to check for one or more of the properties in the above list.

The settings can be changed from the menu option “Tools -> Options -> Web -> Advanced -> Accessibility” options. You can check or uncheck the options as required.

To insert, simply start recording a test. In my case, I am opening the gmail.com page and I am doing this by setting the URL properties in the record and run setting instead of doing it programmatically. As soon as the Gmail.com page opened, I chose the menu option “Insert -> Checkpoint -> Accessibility checkpoint” and click on the page.

The following screen opens up:

Choose the page object and click OK. The properties that can be checked will be displayed for the user to choose one or multiple options. Also, the message at the end of the property selection explains the basis on which the default selection is made.

Let us take a look at what options are chosen at the “Web -> Advanced” pane of the Options dialog box.

This explains why only the “Alt Property check” is selected by default in the “Accessibility Checkpoint Properties dialog box”. If I had a different set of checks ON in the Web -> Advanced pane of the Options dialog box, the same would reflect for any of the subsequent Accessibility checkpoints that you might include in your test.

Click OK on the Accessibility Checkpoint Properties dialog box. As in the case of other checkpoints, the following statement gets added to your test.

 Browser("Gmail: Email from Google").Page("Gmail: Email from Google").Check CheckPoint("Gmail: Email from Google") 

You can modify it just the way you would with any other checkpoints from the OR and the test results will show a pass if the check has passed or failed if it did not.

You can choose to add a check by default to every web page you access by setting the option ON as shown in the below screenshot.

Database Checkpoint

The way this checkpoint works is, you first define a query in your database and create a DB checkpoint that checks the results of the query and thus detects defects.

Two ways to define a Query:

#1) Microsoft query – You can install Microsoft Query from the custom installation of Microsoft Office.

#2) Manually write a SQL query.

I just created a Microsoft Access table named Contacts and added a row with my information. This is how the table looks:

If I want to place a database checkpoint on this. The following are the steps:

Step #1: Select “Insert ->Database Checkpoint” from the menu.

Step #2: In the following screen, select the “Specify SQL Query manually” option and select “OK”.

Step #3: You will need to create a connection string. So click “Create” on the screen.

Step #4: If you already have a DSN created, then choose it from the below screen.

Step #5: If you do not have a created DSN, we will create one. Click on the “New” button and choose your database type from the list available. I am going to choose “Microsoft Access Driver (.mdb, .accdb)” from the list.

Step #6: Click Next and Browse to a location where you would want this DSN to be saved. I chose desktop and clicked OK. On the next screen, click Finish.

Step #7: In the below screen, you can choose to select the data source, i.e the database on which you want to run the query. Click Select and browse for your database.

Step #8: Choose your DB and click OK.  The DSN that you have just created will appear on the list. Select it from the below screen, and click OK.

Step #9: Your connection string is now created. All you need to do is put in the SQL query. To make it simple, I am just going to do a “Select * from Contacts” and click Finish.

Step #10: The results of your query run will be displayed in the “Database Checkpoint Properties” dialog box as follows. You can choose to check for just one column row combination or multiple ones, as you would like in the below screen.

All the other options are also self-explanatory. You can also parameterize the expected results for more complicated scenarios.

Step #11: The settings tab can be used to set the value match criteria.

Step #12: The Cell identification tab can be used to specify the way in which you would want QTP to identify rows and columns.

Step #13: Once the properties are set and the checkpoint is created, the following statement gets added to your test.

 DbTable("DbTable").Check CheckPoint("DbTable") 

Step #14: The test results will show any deviations in the expected and actual results when the test runs.

This concludes QTP checkpoints. Please post your questions and comments.

=> Visit Here For The QTP Training Tutorials Series

Don’t miss the upcoming important tutorials on Automation Frameworks. In the next couple of tutorials, we will discuss the different types of Test Automation Frameworks with examples. By then you can go through all the tutorials published till now.