Free Download for OpenSTA
Monday, March 3, 2008
Monday, February 25, 2008
QTP Descriptive Programming
Descriptive Programming Simplified
This document demonstrates the usage of Descriptive programming in QTP 9.1. It also discusses situations where Descriptive programming can be used. Using Descriptive Programming automation scripts can be created even if the application has not been developed.
1.1 Introduction:
One of the most profound techniques necessary for advanced QTP usage is "Descriptive Programming" (DP).
Descriptive Programming is a technique used to handle automation test even though object repository is not available. Whenever QTP records any action on any object of an application, it adds some description on how to recognize that object to a repository of objects called object repository.
When using DP, we’re bypassing the native object repository (OR) mechanism, which may have many advantages (easy to generate and read code, good data organization, etc.), but is extremely not flexible. We’ll examine situations in which the OR’s advantages are outweighed by the DP’s flexibility.
In order to fully grasp how DP actually works, it’s best to first understand how QTP’s native OR works. The native OR is not some complex and deep mechanism, but rather a simple way of keeping groups of properties and values. To clarify: Whenever we add a certain window to the OR, QTP gathers the window’s/web properties (e.g. – Height="400", Title="New Entity", Name="NewEntityID", html tag="test"), and stores them as a group of property-value pairs. When QTP runs the script, it compares these properties and values to the "physical" objects, and finds (or fails to find) the object which they describe. Nothing mystical about it.
Below screen shots shows an example of Object repository:
QTP uses its object repository to refer to objects present in your test and which have been recorded, if you wish to use objects that were not recorded and are not present in your object repository then we use descriptive programming, where QTP does not refer to object repository but the property name and value are mentioned in the code itself for QTP to use it.
QTP cannot take action on an object until unless its object description is in the Object Repository. But descriptive programming provides a way to perform action on objects which are not in Object repository.
e.g.
This is not Descriptive programming:
Browser(“New Page”).Page(”New Page”).WebButton(“Search”).Click
This is Descriptive programming:
Browser(“name:= New Page”).Page(”title:= New Page”).WebButton(“name:=Search”, “html tag:= BUTTON”).Click
1.2 When and Why to use Descriptive programming?
Below are some of the situations when Descriptive Programming can be considered useful:
1. Functions & Recovery scenarios work with different actions.
Means: Different actions = Different ORs.
2. Can’t record certain objects:
Auto-hide panels
Objects with changing hierarchies
Nested inner-objects, Sub menus
3. The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout <
4. When object repository is getting huge due to the no. of objects being added. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing a object.
5. When you don’t want to use object repository at all. Well the first question would be why not Object repository? Consider the following scenario which would help understand why not Object repository
Scenario 1: Suppose we have a web application that has not been developed yet. Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start of with making QTP scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing.
Scenario 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page. Although there is no limit in QTP9.1 regarding size, but I have found that the moment the size exceeds 80MB, probability of it being crashed increases...
6. Modification to a test case is needed but the Object repository for the same is Read only or in shared mode i.e. changes may affect other scripts as well.
7. When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and there names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach.
1.3 How to use Descriptive Programming?
In DP, we’re "manually" specifying the properties and values by which the relevant object will be identified. This way QTP won’t search for the properties data in the OR, but will take it from the DP statement.
There are two ways in which Descriptive Programming can be used
1. By creating properties collection object for the description.
2. Throw the properties and values straight into a command.
1. By creating properties collection object for the description.
Throw the properties & values into a description object, and throw it into the command. To use this method you need first to create an empty description. DP allows us to define a static descriptive object, and set its properties once. This way, the script simply refers to the descriptive object:
'—-Create Object—-
Dim obj_Desc
Set obj_Desc = Description.Create
'—-Set ID properties & values—
obj_Desc("property1").Value = "value1"
obj_Desc("property2").Value = "value2"
‘—-Use and reuse the description object
Winedit(obj_Desc).Type "Something"
Dialog("Microsoft Internet Explorer").WinButton("obj_Desc").Click
‘—-Release description object—’
Set obj_Desc = Nothing
Each description has 3 properties “Name”, “Value” and “Regular Expression”.
obj_Desc(“html tag”).value= “INPUT”
When you use a property name for the first time the property is added to the collection and when you use it again the property is modified. By default each property that is defined is a regular expression. Suppose if we have the following description:
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt.*”
This would mean an object with html tag as INPUT and name starting with txt. Now actually that “.*” was considered as regular expression.
This is how we create a description. Now below is the way we can use it
Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test”
When we say .WebEdit(obj_Desc) we define one more property for our description that was not earlier defined that is it’s a text box (because QTPs WebEdit boxes map to text boxes in a web page).
2. Throw the properties and values straight into a command
Throw the properties and values straight into a command by specifying property:=value pairs describing the object instead of specifying an object’s name. The general syntax is:
TestObject("PropertyName1:=PropertyValue1", "..." ,
e.g:
Browser(“name:= New Page”).Page(”title:= New Page”).WebButton(“name:=Search”, “html tag:= BUTTON”).Click
TestObject—the test object class could be WebEdit, WebRadioGroup etc….
PropertyName:=PropertyValue—the test object property and its value. Each property:=value pair should be separated by commas and quotation marks. E.g.:
WebButton("name:=Search", "html tag:= BUTTON").Click
It’s the good old syntax we know, except the string between the () is not the object repository name. It’s the property:=value identification string.
Comparison of both methods:
Method 2 is faster, best used for one or two commands. When you want to execute multiple commands on an object, method 1 is a better choice by far (allows one-time definitions, multiple uses).
We can even combine the two methods:
Browser(obj_browser).Page(obj_page).WebButton(“name:=Search”, “html tag:= BUTTON”).Click
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
Sunday, February 24, 2008
Insurance Domain
Quote
Quote is a process of keying in the Customer’s Requirement on to the UWS products to assess the risks and calculate the premium required to cover the risks? The User’s requirements are nothing but the risks they need to be covered and to what extent (Sum insured).
At this time the Customer is called the ‘Proposer’ and the insurance contract has not been signed. During the quote process the insurance company analyses the risks involved and few important decisions are made:
1. Can the risk be accepted?
2. What is suitable premium needed to cover the risk?
The Proposer is informed of the Premium calculated. If the Customer is satisfied and accepted to pay the quoted premium, then the quote gets converted to ‘New Business’. Henceforth, the Customer is called as the ‘POLICY HOLDER’.
What about Back dated/Future dated/Normal Quote based on the user (Internal/External)?
A quote can be effective from a back date or a future date. This however, depends upon the user authority. If the user has the authority of keying a back/future dated quote then only this can be done.
Quote amendments
Once the quote has been made and the Proposer has been informed of the premium; the customer’s need might change for e.g.: - James now wants his friend Hanna to be covered under the Annual Travel Policy, which he had quoted earlier only for him. In that case, the Insurance Company makes the modifications to the already existing quote and re-assesses the risks involved and re-calculates the premium.
This process of changing the already existing quote is known as the Quote Amendment.
Can we include some points about Guaranteed and Non Guaranteed Quote?
If the customer cannot make up mind for converting quote to policy, then the quote can be saved. The customer can come later and then the saved quote can be reopened. A quote can be saved as guaranteed quote, which means that the rate will be valid for certain period of time (normally 60 days).
For non guaranteed it is possible that rating the save quote may result in a different premium.
New business
Once the Proposer is satisfied with the Premiums, then, the quote is converted to New-Business. That means:
1. The Proposer has now become the Policyholder.
2. The contract has been signed.
3. The Risks have been accepted.
4. The customer has accepted the Premium.
5. The customer is covered for the risks involved (which the insurer has accepted) from the Effective date of the policy.
Mid-term adjustments
When some modification has to be done to the Policy after the inception date of the Policy, it will be termed as Mid-term Adjustment.
It can be anything like:
1. Change of the Personal details,
2. Addition of details,
3. Adding additional Covers,
4. Adding another vehicle on to the same Motor Policy, Adding an additional traveler to the same Travel Policy. (I.e. adding an insured unit). Etc.
The effective date of the MTA is entered and any further MTA’S can be done only with an effective date, which falls after the effective date of MTA1.
Can we include some points about the transaction?
Inception Amendment/Cancel Rewrite
If an amendment to the policy needs to be done from the same date as its inception, then this is accomplished through Cancel/Rewrite. It is not advisable to do an MTA on the inception day.
There are two types of cancellations, which can be processed:
Flat cancellation
This might be made due to various reasons:
1. The Customer has not responded.
2. The Customer is unhappy with the insurance Company.
3. The Property has been stolen i.e. Total Loss….
4. The Policyholder is dead.
5. The Object to insured has been sold out.
Etc.
Ideally, total amount of the Premium Paid less processing charges is refunded to the customer.
Pro-rata cancellation
This is nothing but the Mid-term Cancellation i.e. cancellation in the middle of the Policy term. The reasons may be the ones specified above in the case of FLAT CANCELLATION.
The premium paid for the date after the Cancellation Effective date less the processing charges is refunded in this case.
The purpose of Cancel/Rewrite is to revert the policy to its state at the start of the current policy period (New Business or Renewal) to allow the content of the policy to be corrected.
For example, a Major change in the cover has to be made effective to the Policy from the Inception date, then the already existing new business row has to be cancelled and a new row is rewritten.
There are two types of Renewals:
1. Unattended Renewals,
2. Attended Renewals.
Unattended Renewals
Usually the Renewal activity (if the Policy Renewal option was selected as ‘To be Renewed’) is scheduled while creating the New-Business itself.
Renewal Period time Stamp = Current Time Stamp + Policy Term Period.
The Unattended Renewal is the automated CICS Online batch process without any user intervention; it is triggered via the Deferred Activity Queue and scheduled via the Legal Notice Days table. Usually it is 33 days before the Actual renewal day and this window is utilised for sending the ‘Renewal Documents’ to the policyholder.
Attended Renewals
The attended process is a manual process of renewal done via the workstation.
The user selects the Open policy and click on Renewal.
The renewal date has to be filled in and also the term has to be provided.
After this the renewal process will be done without the issue. The renewed policy will be down loaded to the workstation, can be reviewed, rated and issued again. This process will be used for policies on stop and conversion policies.
Reinstatement
Reinstatement is the process of bringing back the policy into IN-FORCE status (i.e. active status) after it has been cancelled.
For example:
The workstation user might have cancelled a Policy in Mistake and wants to bring back the policy into active state.
Other cases might be re-instating the Policy not in
Out of Sequence [OOS] Processing
It is that kind if processing when an MTA has an Inception/Start date before the last amendment. For example: if an MTA has been done on 01-05-2004 and after it has been completed, another MTA is done with effective date 01-03-2004.
This might happen in the following scenarios:
· The issued MTA of the Policy is still in the Queue to be processed and another MTA is issued prior to that.
· Due to Data fix Errors leading to Date inconsistencies.
· Unprocessed Print Triggers.
Main processes involved:
- User issues the policy, upload of the policy.
- Workstation distinguishes if the amendment is out-of-sequence or not.
If yes
The OOS program is called which rates as well
If successful (i.e. the issue process is not out of sequence), then the issue program is called.
Premium Override
Even after the rating has been done and the Premium has been calculated the underwriter has the privilege of overriding the premium.
It can be discount/Loading.
There are two types of overriding:
APO- Annual Premium Override.
TPO- Transaction Premium Override.
Should only be used at NB or Renewal Stage.
TPO
Should only be used Mid Term. It should not be used at NB or RN stage.
Main difference is that
Renewal
The continuation of risk coverage under a policy beyond its original term by the acceptance of a premium for a new term
For e.g.: Policy Inception Date: 01/01/2007 Expiry Date: 31/12/2007
The Renewal Date: 01/01/2008
Types of Renewal:
Manual Renewal (Attended Renewal/Forced Renewal) –
The process by which user manually renew a policy within 90 days of its expiry date.
Automatic Renewal (Unattended Renewal) -
It’s an automated process by which policy is automatically Renewed on the 32nd day from date of expiry of policy, where a renewal stop indicator has not been set to prevent renewal.
Where the previous payment method is Direct Debit policy will automatically continue unless the policyholder advises otherwise.
Renewal Invite Issue
Renewal Invite is issued when a policy term is within 90 – 32 days from its expiry. This Renewal Invite is sent to the customer stating the renewal premium amount
Manual: User can also issue a Renewal Invite manually by clicking on ‘Issue Renewal Invite’ hyperlink present on Premium Results screen within 90 days from date of expiry of policy.
Automatic: Automatically generated on 32nd day from days of expiry.
Fresh Renewal
Any MTA, change, amendment done from the Renewed date is said to be Fresh Renewal. The effective date of the change is the renewed date.
For e.g.: Policy Inception Date: 01/01/2007 Expiry Date: 31/12/2007
The Renewal Date: 01/01/2008
MTA date: 01/01/2008 is said to be Fresh Renewal.
Saturday, February 2, 2008
Subscribe to:
Posts (Atom)