Friday, April 5, 2013

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

What is Test Automation?

Software Testing has always been an essential part of the software industry. With crunch in timelines and increasing scope of testing, Automation can play a key role for getting the Testing phase complete within the stipulated time. Test automation is the process of reducing and whenever possible removing human interactions from an existing manual testing process. There are different tools available in the market o achieve test Automation of the Application under Test (AUT). With variety of environments available in the market to develop an application, it gets difficult to get one tool which can cater to all the needs of the Applications. Quick test Pro (QTP) does support a lot of environment through the use of Add-ins specified to the environment.

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

Thursday, April 4, 2013

Risk Life Cycle

The life cycle involved the below stages

    • Risk Identification.
    • Risk prioritization.
    • Risk planning.
    • Risk monitoring.

In Risk identification stage, all the members of the projects do a brain storming and identify the possible risks for the project. Few risks will also be included from the risk database that is maintained by the organization.

In Risk prioritization stage, the impact would be measured using a formula that includes the probability and the impact. Depending on this prioritization would be done to focus on the high severe risks. During this stage few risks will be eliminated if they don’t have a considerable impact on the project variables.

In Risk planning stage, the mitigation and contingency plans for each of the prioritized risks will be identified and implemented.

In Risk monitoring stage, all the risks will be monitored to ensure that the mitigation plan that is in plan is yielding results and the risks doesn’t occur or if occurred the impact is minimized. If the mitigation plan is not yielding the expected results then the plan would be changed and few more controls would be placed to ensure that the impact is minimized. Also risk identification would be done regularly during the course of the project to identify new risks and then the life cycle follows

AI in Software Testing: How Artificial Intelligence Is Transforming QA

For years, software testing has lived under pressure: more features, faster releases, fewer bugs, smaller teams. Traditional QA has done her...