Quick Test Professional 9.

2
Testing Process

 Preparing to Record
 Recording
 Enhancing a Test
 Debugging
 Running the Test and Analyzing the Results
 Reporting Defects
Add-in Manager

 Default Add-ins
– ActiveX
– Visual basic
– Web

 Other Add-Ins
– Siebel
– Java
– SAP
– Oracle
– .Net and many more
Quick Test Professional - Record &
Run Modes

 Recording Modes
– Normal
– Analog
– Low level

 Run Modes
– Normal
– Fast
QTP Window
Create a Test

Objectives
 Create a basic test from a manual test case.
 Run a test and check for errors.
The Object Repository

• Object repository dialog box

displays a test tree of all
objects in the current action or
the entire application.
•Using Object repository we
can
a) Identify the Object
b) View the Object Properties
Object Spy

 Using the Object Spy,

we can view the
properties of any
Object in the open
application.
 We can also view
Object Methods.
How Quick Test Recognizes Objects

 For each object class, QTP has a default set

of properties that it always learns.
1.Mandatory Properties.
2.Assistive properties.
3.Ordinal Identifier.
 Usually, only a few properties are needed to
uniquely identify an object.
Synchronization

 Synchronization point enables the anticipated time

problems between the application and QTP.
 A progress bar reaches 100% completion.
 A status message appears.
 A button becomes enabled.
 A window opens and is ready for data entry.
 A pop-up message appears in response to an
operation.
How to synchronize the Test

 We can synchronize the test by

1.Inserting a synchronization point
Insert  Step  Synchronization point
Window(“Flights”).WinButton(“Update order”).WaitProperty”enabled”,1,1000

2.Adding Exist and Wait statements

status=Window(“Flights”).Dialog(“Flights Table”).Exist
Wait(10)
Checkpoints

 A checkpoint is a verification point that compares a

current value for a specified property with the
expected value for that property.
 We can Insert checkpoint
1.From Menu
Insert  Checkpoint  Standard Checkpoint
2.From Keyword view
3.From the Active Screen
Checkpoint Types

1.Standard Checkpoint
2.Image Checkpoint
3.Table Checkpoint
4.Page Checkpoint
5.Text Checkpoint
6.Text Area Checkpoint
7.Bitmap Checkpoint
8.Database Checkpoint
Insert A Checkpoint From The
Active Screen
 A checkpoint can be added
after a test is created.
 Use the Active Screen to
select the field on which the
checkpoint will be added.
 Right-click on the
appropriate field and
choose “Insert Standard
Checkpoint”.
Regular Expressions

 Regular expressions enable Quick Test to Identify

Objects and text strings with varying values.
Use a Regular Expression

 A regular expression is a string that

specifies a complex search phrase.
By using
 special characters you define the
conditions of the search.
 Note: There are 4 steps to ensure that
a regular expression is inserted
correctly.
 From the Checkpoint Properties
window, ensure Constant is enabled
and click on the note paper icon.
 Check Regular Expression checkbox.
 If QTP sees there are characters that
can be misconstrued as a regular
expression, it will ask you to treat it
as a literal character. Generally, you
will answer No.
 Add the regular expression. For
example, Figure 6-6 will use [A-Z a-
z]+.
Parameters

 Objectives
 Describe and use multiple parameter types.
 Drive data in multiple iterations.
 Analyze errors during iterations.
 Parameterize a checkpoint.
Input Parameters For Data driven
Tests
 Input Parameters For Data Driven Tests
 A data-driven test is one that runs a set of user
actions with multiple input values. Data driving
allows one script to test application functionality
with many sets of data.
 Automated data driven testing frees you to
perform more tests, thus increasing test coverage.
Speed, repeatability, free resources to do other
kinds of quality control.
Input Parameter

 Input Parameters allow you to

replace a static, recorded
value in a step with a dynamic
placeholder (parameter),
which represents an
expandable range of values.
 Input parameter names and
their values are located in
QuickTest’s Data Table.
 Input parameter values are
input into the application from
some outside data source.
Steps to Create An Input Parameter

 To create an input data table

parameter:
 Select the step in the Keyword
View that contains the recorded
input value.
 From the Value column, click on
the current value.
 Click on the parameterize
button.
 The Constant value appears in
the Value Configuration Options
dialog box.
Set the Parameter Value

 In the VALUE
CONFIGURATION OPTIONS
dialog, select the Parameter
radio button and ensure that
Data Table is selected from the
drop-down list.
 From the Name drop down list,
enter a unique column name to
create a new column in your
data table or choose an existing
column name from the data
table.
 Use the default Global data
sheet to store values.
 Enter the values that QTP will
input after the test executes.
Supply Data to the Parameter

 The design-time table is the

central location for storing input
parameter values.
 The number of rows in the data
table will cause the same
number of test execution
iterations to be run.
 As a default, the design-time
data table is displayed at the
bottom of the QuickTest screen.
 If you want to show or hide the
data sheet, click on the icon in
the toolbar.
Verify The Test Run

 View the Test Results

window to verify that each
of the rows from the
Design Time Data Table
was used during the test
run.
 Expand the tree for each
iteration (Row#) to view
specific information about
the execution of the
specific row.
Parameterize a Checkpoint

 You can use parameterized

expected values to make
your checkpoints dynamic.
They Can be set on:
 An object property in the
Object Repository.
 A checkpoint on a
parameterized field.
A Test with Multiple Actions

 Actions can be divided into

logical sections, like the
main sections of a
transaction, or by specific
business processes.

 When you create a new test,

it contains one action. By
dividing your tests into
multiple actions, you can
design more modular and
efficient tests.
Types of Actions

 There are two kinds of actions:

Regular (Non-reusable)
Reusable

 Tests that contain reusable actions can be used:

Locally
Externally
Insert Call to a New Action

 You can add a new action

during or after recording.
 Select Insert ? New Action
from the QuickTest main
menu. The Insert New
Action window appears.
 Or use the “lego” icon on the
toolbar to insert new action.
Using Parameterized Data

 Test data can be passed from

one test to another test using
the value of an input parameter.

 This creates a data flow

between business processes.

 The value passed from one

business process to another will
come from the Data Table.

 Be aware of any data

dependencies that occur within
the business process.
Copied, Existing or New Action

 After reusable actions are

created, they can be called
into a “Main Calling” test
in three ways:
 Call to New Action
 Call to Copy of Action
 Call to Existing Action
Set Actions as Reusable

 Create a reusable
action from the Action
properties dialog.
 Check the checkbox
and click OK. A
message will appear
stating a description of
a reusable
 action.
Call An Action

 You can do number of things with a

reusable action, such as:
 Call it multiple times within a test.
 Call it from other tests.
 View the components of the action tree
(you cannot modify them except in the
original script)
 Insert a call to an external action (the
action is inserted in read-only format)
 as local editable copy
 use the (read only) data from the
original
 action
 Insert copies of non-reusable actions
into your test, but you cannot insert calls
to non-reusable actions.
Recovery Scenarios

 To instruct Quick test to recover from unexpected

events and errors that occur in the testing
environment during the run session.
 A Recovery scenario consists of
a) Trigger Event
b) Recovery Operation
c) Post Recovery Run Option
Recovery Scenario Wizard

 We can create the recovery scenario using recovery scenario

wizard.
 Recovery scenario wizard consists of
a) Define the trigger event that interrupts the run session
b) Specifying the recovery operations required to continue
c) Choosing a post recovery test run operation
d) Specifying a name and description for the recovery scenario
e) Specifying whether to associate the recovery scenario to the
current test and / or to all new tests.
Recovery Scenario Wizard
Creating Tests without Object Repository

 We can use programmatic descriptions to perform an operation on an

object that is not stored in the Object Repository.
 Types of Programmatic descriptions
a) We can list the set of properties and values that describe the object
directly in a test statement.
e.g: Dialog(“name:=Login”).WinEdit(“attachedtext:=agentname”).Set”impetus”
b) We can add a collection of properties and values to a description
object and then enter the description object in the statement.
Set myobject=Description.Create()
myobject(“attachedtext”).value:=“agentname”
myobject(“html tag”).value:=“a”
Dialog(“name:=Login”).WinEdit (myobject).Set”impetus”
Enhance TestCases With
Descriptive Programming
 Interact with Test Objects not stored in the Object Repository
– You can also instruct QT to perform methods on objects
without referring to the object repository without referring to
the object’s logical name. To do this you provide QT with a
list of properties and values that QT can use to identify the
object or objects on which you want to perform a method
Enter Programmatic Descriptions
Directly into Test Statements
 You can describe an object directly in a test statement by
specifying property : = value pairs describing the object
instead of specifying an object’s logical name.
 Syntax:-
 TestObject(“PropertyName1:=PropertyValue”, “…”,
“PropertyNameX:=PropertyValueX”)
 Where “Test Object” is test object class
Contd….
 PropertyName is PropertyValue
 i.e. the test object property and its value . Each property:=
value pair should be separated by commas and quotation
marks.
 For Example: Window(“Text:=Myfile.txt-Notepad”).Move 50,50
 If you want to use the same programmatic description
several times in one test, you may want to assign the
object you create to a variable.
 For Ex:- Set MyWin := Window(“Text:=Myfile.txt-Notepad”)
 MyWin.Move 50,50
Contd….
 Once we have filled the Properties collection with a set of Property
objects (properties and values), you
Can specify the Properties object in place of a logical name in a test
statement.
For Ex:- (Instead of Entering)
Window(“Error”).WInbutton(“text:=OK”, “width:=50”).click
IF Entered…
Set MyDescription= Description.Create()
MyDescription(“text”).Value=“OK”
MyDescription(“width”).Value=50
Window(“Error”).WinButton(MyDescription).Click