Standard check point

It is used to test the GUI properties of the objects like : Text, Enabled, Height, width, class etc.,

Navigation: Record mode -> Insert menu -> check point -> Standard check point -> select the handler pointer -> click on the object which we want to check the properties -> specify expected values -> Click OK button -> stop recording.

Syntax: <obj hierarchy>.check checkpoint(<check point name>)

To find the status of check point:

Val=<obj hierarchy>.check (checkpoint(<check point name>))

Ex: Focus to window

-> Flight button should be disable

Open a new record

-> Flight button should be disable

Enter date

-> Flight button should be disable

Select Fly From

-> Flight button should be disable

Select Fly To

-> Flight button should be enable

Contributed by: Vamshi Gowtham m.vamsigowtham@gmail.com

Check points

Check points are used to verify the properties of GUI objects, Images, data bases…..

Check points allows us to compare the current behaviors of the application with earlier behavior of the application.

Types of check points:

1.     Standard check point

2.     Text check point

3.     Text area check point

4.     Bitmap check point

5.     Data base check point

6.     Accessibility check point

7.     XML check point from Application

8.     XML check point from Resource

Operational overview of Check point:

IT is divided into 2 phases.

1.     Pre-Execution phase :

i) Captures the expected value

ii) Generates the corresponding test script statement

2.     While Execution phase:

i) Captures the actual value

ii) Compare the actual value with expected value

iii) Display the result.

Disadvantages:

1.     It takes more time to verify and validate and hence test execution time is more

2.     It depends on the screen resolution and hence it might vary from system to system.

Note: In real time we mostly avoid use of check points.

Contributed by: Vamshi Gowtham
m.vamsigowtham@gmail.com

Types of Objects

There are 2 types of objects:
1.    Test objects (TO)
2.    Run – time objects (RO)

Test Objects: Test objects are QTP defined classes used to represent the various objects in the application under test (AUT)
Runtime Objects: Run time objects are the actual AUT objects which a Test Object refers/points to during test execution.

Comprehending the difference between these two object types is very important. Consider two cars; Car A and Car B. QTP would represent both cars using a Car Test object in the script. In addition, each Test Object also provides methods and properties used to interact with its associated Run-time object. For example, methods like Start, Run and stop would be useful methods provided by a Car Test Object.

TO Properties:
 
Test Object properties are those properties that QTP maintain in the OR for identifying a Run-time object during test execution. QTP allows enumeration of all TO properties using GetTOProperties  method. GetTOProperty and SetTOProperty are used to read or modify the TO property values respectively.

Working with Test Object Properties

1)    Retrieving Test object property value one by one
 
Add that object to OR.
 
Msgbox <obj hierarchy>.GetTOProperties(“property name”)
 
Ex:  msgbox Dialog(“Login”).GetTOProperties(“text”)
     Msgbox Dialog(“Login”).GetTOProperties(“native class”)
       Msgbox Dialog(“Login”).GetTOProperties(“is owned window”)
       Msgbox Dialog(“Login”).GetTOProperties(“is child window”)
   
2)    Retrieving Test object all property values at a time

Add required object to OR. (Ex: Add Sample application Dialog window to OR )

‘Get the required object
Set obj=Dialog(“Login”)

‘Get the total TOProperties collection for dialog object
Set TOProps=obj.GetTOProperteis()

‘Loop for all property
For i=0 to TOProps.Count – 1
    propertyName=TOProps(i).Name
    PropertyValue=TOProps(i).Value
    isRegularExp=TOProps(i).RegularExpression
msgox “Property name   “&propertyName&”  Property value  “&propertyvalue&”                                                                 
regularexp “&isRegularExpr
           Next
   
3)    Changing Test Object Properties at run time.

Syntax: 

<obj hierarchy>.SetTOProperty “property name”,”new property values”

Add required object to OR. (Ex: Add Sample application Dialog window to OR )
Dialog(“Login”).SetTOProperty “text”,”Login screen”
Msgbox Dialog(“Login”).GetTOProperty(“text”)

Note: If object properties are changing at run time then we are set the property.
Ex: Start button to Stop button.
       Play button to Pause button.

Working with Run-time Object Properties

4)    Retrieving Run-time object property vlaues during test execution

Syntax: <obj hierarchy>.GetROProperty(“property name”)

Contributed by: Vamshi Gowtham
m.vamsigowtham@gmail.com

Object Repository

Object Repository: OR is a storage place where we can store the object information and it also acts as an interface between Test script and AUT in order to identify the objects during execution.

Adding objects to OR:
Objects can be added to the OR using one of the two methods:
1.    By recording interactions against the application under test
2.    By manually adding one or more objects.

Navigation for manual way:  

Click on OR icon -> Click on Add objects to Local icon -> with handler icon show the object which is going to add -> Select the Define Object Filter (Selected object only, Default object type, All objects, selected object types) -> Click OK button
 
Object Repository Types:

There are 2 types of object repositories.
1.    Per Action
2.    Shared

Per Action: If at all, this type is selected the QTP will create and manage an individual repository separately for each and every action.
Extension: .mtr (module test repository)

Shared repository: Maintaining same OR to multiple tests or actions is called Shared OR

Navigation for creating SOR:
 
Click on OR icon -> Collect the objects into the OR -> File -> Export Local objects…->specify file name with extension .tsr

Navigating for associating SOR:

1)    Click on OR icon ->Tools-> Associate Repositories ->Click on ‘+’ icon ->retrieve the required or file ->Select Associate actions from Available actions -> Click on OK button.

2)    Resources menu -> Associate Repositories -> Click on ‘+’ icon ->retrieve the required or file ->Select Associate actions from Available actions -> Click on OK button.

Navigation for disassociating SOR:
1) Click on OR icon ->Tools-> Associate Repositories ->Select the existing OR file ->Click on ‘-’ icon
2) Resources menu -> Associate Repositories -> Select the existing OR file ->Click on ‘-’ icon

Object Repository operations: (Add, Rename, Delete objects/properties)
   
1)    Navigation for adding objects information:
Click on OR icon -> Click on Add objects to Local icon -> with handler icon show the object which is going to add -> Select the Define Object Filter ( Selected object only, Default object type, All objects, selected object types) -> Click OK button
2)    Navigation for renaming objects in OR:
Object Repository popup -> select the desired object -> right click on it -> Select the option rename -> specify the desired name
3)    Navigation for deleting objects in OR:
Object Repository popup -> select the desired object -> right click on it -> Select the option delete ->click on Yes on confirmation message.
4)    Navigation for updating the list of properties of an object:
OR popup -> select the desired object -> click on +/- buttons -> select the desired properties to be added or removed -> Click OK button.
5)    Navigation for updating property value:
OR popup -> select the desired object  -> select desired property in property list -> Specify the desired value in the constant field of configuration value section -> click OK button.

Highlight:
 
When ever Test Engineer is confused with some objects information in the OR window then by    
 
Highlighting the corresponding object he can get clarification which object information is that.
   
Select the object in OR -> Click on Highlight button.

Object Spy:
 
The object spy is a tool used to interrogate methods and properties supported by an object.
 
Tools -> Object Spy    (or)    click on Object Spy icon.

Contributed by: Vamsi Gowtham
m.vamsigowtham@gmail.com

Architecture of QTP

QTP window is divided into 5 parts:

1)    Test pane:  Test pane is an area provided by QTP, which is used for viewing the test script and it also allows the user to do any kind of modifications on it.
It represents the scripts in two views: Keyword View, Expert View
 
Keyword View: It represents VB Script in GUI format
It is divided into 4 parts: 1) Item 2) Operation 3) Value 4) Documentation

Expert View: It represents the script in VB script format.
 
2)    Active screen: Active Screens holds the snapshots for each and every script statement.
It is used for understand the script easily and enhance the script easily.
 
3)    Data Table : It is also called a Formula1 sheet
       1.    It holds test data
       2.    It can import the test data from the difference data sources
       3.    It associates the test script from the data source
       4.    It allows the user to directly interact wit it
       5.    QTP maintains 2 types of data table
 
Design-Time and Run-Time data table
 
4)    Information pane: It holds all syntactical errors
5)    Tool option: All the remaining options available in menu bar, File Tool bar are known as tool options.

Contributed by: Vamsi Gowtham
m.vamsigowtham@gmail.com

When should Test Automation be avoided?

It is utmost important to make sure that test cases automated are right one. Not every manual test case is a good candidate for automation. Knowing which test cases are not t be automated is important. Some examples of test cases which should not be automated are listed below:

1.    In the case of Ad hoc testing where a subject matter expert randomly prowls through a variety of combinatorial workflows.
2.    In the case of One time testing or when testing is repeated only a few times.
3.    In the case of testing which requires covering multiple functional areas so that the test travels through a small amount of virtually all of the product’s functionality
4.    Testing where look and feel, color, table layout etc. are validated
5.    Testing where pass/fail validation requires evaluating information from several different and unrelated systems and/or applications
6.    Test cases for which test data cannot be determined before hand
7.    Test cases for which automated version execution takes more time than manual execution
8.    Test cases for which development of the automated scripts takes more time.

Contributed by: Vamsi Gowtham
m.vamsigowtham@gmail.com

When should Test Automation be used?

Automation is not replacement of annual testing. 100% automation can be achieved only in certain case, not always. It is important in Automation to decide which test cases need to be automated and which test cases need to be tested manually. Given below is the list of few parameters which makes manual test cases a good candidate for automation:

1.    The test must be repeated very often
2.    The tests workflow and its validation evolve and change slowly over time.
3.    The test validates a business process or workflow, rather than validating the look and feel, color, table layout, etc.
4.    The test is very repetitive and/or has a lot of steps, and it is important that those steps be performed exactly the same way each time and where manual tester fatigue must be avoided
5.    The test produces results for a regulatory body that demands that those results be electronically recorded and archived as a formal evidence of compliance.
6.    Te test’s pass/fail results are reasonably easy to determine and capture with the selected automation tool

Contributed by: Vamsi Gowtham
m.vamsigowtham@gmail.com