All about QTP Descriptive Programming

What is Descriptive Programming?

In QTP if we want to do some actions/operation on an object that is not there in the object repository then we can use or go for Descriptive programming.

With out using QTP OR we can store properties of Test objects in the QTP Script by defining the Object properties.

Advantages of Descriptive Programming:

1. We will be able to work on writing QTP scripts even before the application is NOT available. It will help to increase the utilization of the Automation scripts as it will be immediately available once the application get released.

2.We can define the properties of an object without considering the parent objects in the hierarchy. i-e Object identification will not depend on its parent object.

there are 2 ways to describe your Test Objects.

One is description in form of the string arguments.

For Ex:  text box having html code as < input type=”text” name=”txtUserSiva” > can be accessed as below.

Browser(“Browser”).Page(“Page”).WebEdit(“Name:=txtUserSiva”,”html tag:=INPUT”).set “AutomationTestingwithQTP”.

The 2nd way is using Decription.create as below.

Set objDesc = Description.Create

objDesc(“html tag”).value= “INPUT”

objDesc(“name”).value= “txtUser”

Browser(“Browser”).Page(“Page”).WebEdit(objDesc).set “AutomationTestingwithQTP”.

Disadvantage of Descriptive Programing:

First disadvantage of Descriptive programming is Maintenance will be difficult.
Since Object repository will be stored in centralized place, property definition for any Object can be easily changed at any time if the application developer changes the property of the actual object/control.

But, in descriptive programming (DP) it is difficult to change the object property as each QTP developer will be defining object property in many places using DP.

For example, assume that you and team member are developing automation test scripts for testing gmail application.
Gmail login script will be used in many test scenarios.

Assume that you are automating some scenarios and your team member is automating some other scenarios.
In case of Object Repository, you and your team member will be forced to use same object description for login page controls/Objects (e.g username, password, login button).

So in future if Google changes any property (e.g change the button name from “login” to “get into gmail”), all the scenarios can be easily updated just by updating this change in Object repository.

But in case of DP, there is a possibility of defining the login button in multiple places. One definition by you and another by your team. (Anyway proper Team Coordination will avoid this issue, but practically it is very difficult to achieve this coordination.).

So, comparatively updating DP style coding is bit difficult if the application properties got changed.