QTP Tutorial #17 Test Automation

Frameworks Keyword Driven and Linear

Framework Examples
What is Test Automation Framework?
In the context of successful implementation of QTP for a software testing project we often come
across the concept of frameworks. Framework is nothing but the approach that we consistently
follow during the automation process a set of guidelines.
Personally, I dont like to give names and say that one works better than the other. The selection
of a certain framework is not the beginning of a project. It is the reverse that is true. In the
process of devising a testing strategy you build the rules that are applicable to the testers current
situation and that right there is your framework.
Having said that, the following are some of the important points we need to consider:
1. Reusability
2. Scripts easy maintenance
3. Readability of scripts
4. Good workable folder structure for all the test assets
5. No hard coding values
6. No cascade of failures. (i.e. if one test fails, it should not cause the failure or stopping of the
others)
This is the basic list and more can be added based on the requirement.
Any testing strategy that tries to incorporate some or all of these above points is your Test
Automation Framework.
There are various names and types of frameworks. The following is the list of frameworks
according to me:
Types of Automation Frameworks:

1. Linear Simplest form of creating a test. Just write a one single program without modularity in
sequential steps
2. Keyword driven Create different keywords for different set of operations and in the main
script we can just refer to these keywords.
3. Data driven To run same set of operations on multiple sets of data that are kept in separate
files, mostly excel sheets.
4. Hybrid A combination framework that can be partly data driven and partly keyword driven
5. BPT This just means that programs are broken down into business components and are used
with one or the other of the above types of frameworks
Linear Framework
As discussed this approach involves simply writing the code as we record and keep going.
For example, if the operation that you have to verify is the creation of a new account in gmail the
following will be the steps:
a) Open gmail.com
b) Click on Create Account
c) Enter the details
d) Verify the details
e) Create the account





'Open GMail
SystemUtil.Run "iexplore.exe", "http://www.gmail.com"
'Page Sync
Browser("Gmail").Page("Gmail").Sync
Click on create account
Browser("Gmail").Page("Gmail").WebLink(Create Account).Click
Enter the details
Browser("Gmail").Page("Google Accounts").WebEdit(First Name).Set Swati
Browser("Gmail").Page("Google Accounts").WebEdit(Last Name).Set test
Fill in several other details
Submit
Browser("Gmail").Page("Google Accounts").WebButton(Next Step).click

The above is an example of how a program that uses the linear method looks like. It is obvious at
this point what the advantages and disadvantages of this method are.
Advantages:
1. Simplicity. For beginner programmer this method is apt
2. Time It does not take a lot of time to create the test
3. Very little planning is required
Disadvantages:
1. No reusability at all
2. If there is another script that verifies a certain aspect of the Google Accounts Page then you
will have to rewrite the code to launch gmail.com page too. So lots of repetition.
3. All the data is directly embedded into code. The hard coding does not let the code be used for
any other set of data.
4. Error prone and maintenance is difficult
While the cons outweigh the pros, this method can be used when your aim is strictly to
accomplish a task without validations.
The components or test assets in this kind of frameworks are:
1. Test script
2. Object repository (This can be avoided by using descriptive programming if needed)
Keyword driven Framework
How can we make the above linear framework test better? How can we overcome the cons?
Obviously, we need reusability, modularity and readability. Trying to incorporate these features
and arriving at an optimum solution is nothing but an attempt at creating a new, more improved
framework.

What are the reusable components?
Launching of gmail and arriving at the Google Accounts page. This is a given, since
validating this page means to first get here. GoTo Google Account can be made into a
separate function that can be called over and over again.
Enter the details and validating them You can further break this up into positive and negative
blocks to include more level of modularity
Account creation The final level of validation and accomplishing the task at hand
Once you have arrived here, not only have you identified components that can be called over and
over again, but you have also broken you linear program into modules.
Functions:
So far in our series we have not dealt with functions. Functions are nothing but a piece of code
that does a certain operations. It accepts input parameters from the program that calls it and
returns value to it.
As a general practice all the reusable pieces of code are grouped into a file that contains all the
reusable functions. This file is associated as a resource to your QTP test. Typically a function
library can be a file of the type: .vbs, .txt or .qfl
Back to our example This is how the function library file can be:
Function gotoGoogleAccount()
'Open Gmail
SystemUtil.Run "iexplore.exe", "http://www.gmail.com"
'Page Sync
Browser("Gmail").Page("Gmail").Sync
Click on create account
Browser("Gmail").Page("Gmail").WebLink(Create Account).Click
Enter the details
End Function
Function EnterDetails()
Browser("Gmail").Page("Google Accounts").WebEdit(First Name).Set Swati
Browser("Gmail").Page("Google Accounts").WebEdit(Last Name).Set test
Fill in several other details
End Function

Function SubmitToCreate()
Submit
Browser("Gmail").Page("Google Accounts").WebButton(Next Step).click
End Function





Now your actual script will be:

'Open GMail
gotoGoogleAccount()
Enter the details
EnterDetails()
Submit
SubmitToCreate()

From the above program it is now clear that we have achieved readability, modularity and if in
case another program wants to use the login function, we can surely reuse it. All you have to do
is associate the function library to that new test too and you are good to go.
You can also see that in your script the function names are functioning as if they are VBScripts
keywords and hence the name for this framework.
The components or test assets in this kind of frameworks are:
1. Test scripts
2. Shared OR
3. Shared function library
Now, what else would make this program even better? If we could make the EnterDetails()
function to take different sets of data and create different accounts and not be limited to the data
that we hard coded into the program. That exactly is the next step. Data driving your tests and the
approach where we do this is the data driven framework.




















QTP Tutorial #16 Steps to Insert XML,
Accessibility, and Database Checkpoints
Today we will continue with 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 last 4 tutorials.
XML checkpoint:
By adding XML checkpoints to your test, you can check the contents of individual XML data
files or documents that are part of your Web application.
1. You can perform checkpoints on XML documents contained in Web pages or frames, on
XML files, and on test objects that support XML.
2. 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.
3. When you insert a checkpoint, QuickTest adds a checkpoint step in the Keyword View
and adds a Check CheckPoint statement in the Expert View.
4. 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:
1. XML Web Page/Frame Checkpoint. Checks an XML document within a Web page or
frame.
2. XML File Checkpoint. Checks a specified XML file.
3. 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 in this screen and click OK
Step #5)
Browser("Browser").Page("Page").WebXML("http://www.w3schools.com/xml/c").Chec
k 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 above ones.
The option XML checkpoint(from application) is available only when the web add in 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 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 an 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 a Gmail.com page and I am
doing this by setting the URL properties in the record and run setting instead of
programmatically. As soon as the Gmail.com page has 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 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 the 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 do 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 on 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: (click to enlarge image)

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 Specify SQL Query manually option and select Ok.

Step #3) You will need to create a connection string. So click Create in the screen
Step #4) If you already have a DSN created. 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 for a location where you would want this DSN to be saved. I
chose desktop and click Ok. In 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 in the
list. Select it from the below screen, and click OK.

Step #9) You connection string is now created. All you need to do is put in the SQL query. For
simplicitys sake 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 columnXrow
combination or multiple ones, as you would like in the below screen. All the other options are
also self explanatory. You could 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.
1 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.




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 checkpoint can be used to check text and discussed the text checkpoint in detail.
The next checkpoint is Text area checkpoint. Lets begin exploring it.
Note We have aggregated links to all these QTP training tutorials on this first QTP tutorial.
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 a 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 checkpoint 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, 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 in 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
parameterize.
In the settings tab, 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 I said earlier, since this is a variation of standard checkpoint all the same rules apply.
Although, this in-built feature is available for checking tables I dont 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. Eg: 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 kind of defeats the purpose and results in unnecessary
continuation of checking the other cells.
Instead by reading the table and using GetRowCount, GetColumnCount, GetRowItem functions
you can establish a looping mechanism and check as needed and exit on failure. 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 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:
1. Checking links
2. Sources of images
3. 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. The users can choose number of properties as required.
As it 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.

Next section is the HTML verification:
- HTML source: Checks if the HTML code for the web page matches the actual one at run time.
The user has an option to modify it as required while creating a checkpoint and check if it
matches at run time.
- HTML tags: Checks the HTML tags for the web page at record and run times. As with HTML
source, HTML tags can be modified too.
All Objects in the page section:
a) 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 again can be a constant or a parameterized value.
b) Images: Checking this ON means that you can verify the presence of the images on the page at
run time. On clicking Filter Image Check the user can select the exact images that are to be
checked and the ones that has to be ignored.
The following tab gets displayed when the user chooses to Filter:

As usual, the user can configure the values.
c) Broken Links: This option is not usually ON by default and on checking it ON, it verifies if
there are any broken links in the web page.
The user can check for broken links that are only for 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 Tools-
>Options->Web menu option.

Once this checkpoint is run all the failures, if any will be displayed the Test Results. Otherwise
the checkpoint passes.
Some of the Page Checkpoint options are available only when the checkpoint is created during
recording. If you try to create them from Active screen or Keyword view, the HTML verification
options wont 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.

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