How to get Child Objects?

We can use description object to get all the objects on the page that matches that specific description. Suppose we have to check all the checkboxes present on a web page. So we will first create an object description for a checkboxe and then get all the checkboxes from the page

Dim obj_ChkDesc

Set obj_ChkDesc=Description.Create

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

obj_ChkDesc(“type”).value = “checkbox”

Dim allCheckboxes, singleCheckBox

Set  allCheckboxes = Browse(“Browser”).Page(“Page”).ChildObjects(obj_ChkDesc)

For each singleCheckBox in allCheckboxes

      singleCheckBox.Set “ON”

Next

The above code will check all the check boxes present on the page. To get all the child objects we need to specify an object description i.e. we can’t use the string arguments that will be discussed later in the 2nd way of using the programming description.

Possible Operation on Description Object

Consider the below code for all the solutions

Dim obj_ChkDesc

Set obj_ChkDesc=Description.Create

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

obj_ChkDesc(“type”).value = “checkbox”

Q: How to get the no. of description defined in a collection

A: obj_ChkDesc.Count ‘Will return 2 in our case

Q: How to remove a description from the collection

A: obj_ChkDesc.remove “html tag” ‘would delete the html tag property from the collection

Q: How do I check if property exists or not in the collection?

A: The answer is that it’s not possible. Because whenever we try to access a property which is not defined its automatically added to the collection. The only    way to determine is to check its value that is use a if statement “if obj_ChkDesc(“html tag”).value = empty then”.

Q: How to browse through all the properties of a properties collection?

A: Two ways

      1^st:

                  For each desc in obj_ChkDesc

                              Name=desc.Name

                              Value=desc.Value

                              RE = desc.regularexpression

                  Next

      2^nd:

                  For i=0 to obj_ChkDesc.count - 1

                              Name= obj_ChkDesc(i).Name

                              Value= obj_ChkDesc(i).Value

                              RE = obj_ChkDesc(i).regularexpression

                  Next

2.      By giving the description in form of the string arguments.

You can describe an object directly in a statement by specifying property:=value pairs describing the object instead of specifying an object’s

name. The general syntax is:

TestObject("PropertyName1:=PropertyValue1", "..." , "PropertyNameX:=PropertyValueX")

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. Note that you can enter a variable name as the property value if you want to find an object based on property values you retrieve during a run session.

Consider the HTML Code given below:

Now to refer to the textbox the statement would be as given below

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

And to refer to the radio button the statement would be as given below

Browser(“Browser”).Page(“Page”).WebRadioGroup(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”

If we refer to them as a web element then we will have to distinguish between the 2 using the index property

Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=0”).set “Test” ‘ Refers to the textbox

Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=1”).set “Test” ‘ Refers to the radio button

Hierarchy of test description

When using programmatic descriptions from a specific point within a test object hierarchy, you must continue to use programmatic descriptions

From that point onward within the same statement. If you specify a test object by its object repository name after other objects in the hierarchy have

Been described using programmatic descriptions, Quick Test cannot identify the object.

For example, you can use Browser(Desc1).Page(Desc1).Link(desc3), since it uses programmatic descriptions throughout the entire test object hierarchy.

You can also use Browser("Index").Page(Desc1).Link(desc3), since it uses programmatic descriptions from a certain point in the description (starting

from the Page object description).

However, you cannot use Browser(Desc1).Page(Desc1).Link("Example1"), since it uses programmatic descriptions for the Browser and Page objects but

then attempts to use an object repository name for the Link test object (QuickTest tries to locate the Link object based on its name, but cannot

locate it in the repository because the parent objects were specified using programmatic descriptions).

How to use Descriptive programming?

There are two ways in which descriptive programming can be used

1.      By creating properties collection object for the description.

2.      By giving the description in form of the string arguments.

1.      By creating properties collection object for the description.

To use this method you need first to create an empty description

Dim obj_Desc ‘Not necessary to declare

Set obj_Desc = Description.Create

Now we have a blank description in “obj_Desc”. 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. So, if you want the property “name” not to be recognized as a regular expression then you need to set the “regularexpression” property as FALSE

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

obj_Desc(“name”).value= “txt.*”

obj_Desc(“name”).regularexpression= “txt.*”

This is how of 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).

If we know that we have more than 1 element with same description on the page then we must define “index” property for the that description

Consider the HTML code given below

Now the html code has two objects with same description. So distinguish between these 2 objects we will use the “index” property. Here is the description for both the object

For 1^st textbox:

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

obj_Desc(“name”).value= “txt_Name”

obj_Desc(“index”).value= “0”

For 2^nd textbox:

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

obj_Desc(“name”).value= “txt_Name”

obj_Desc(“index”).value= “1”

Consider the HTML Code given below:

We can use the same description for both the objects and still distinguish between both of them

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

obj_Desc(“name”).value= “txt_Name”

When I want to refer to the textbox then I will use the inside a WebEdit object and to refer to the radio button I will use the description object with the WebRadioGroup object.

Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test” ‘Refers to the text box

Browser(“Browser”).Page(“Page”).WebRadioGroup(obj_Desc).set “Test” ‘Refers to the radio button

But if we use WebElement object for the description then we must define the “index” property because for a webelement the current description would return two objects.

When and Why to use Descriptive programming?

Below are some of the situations when Descriptive Programming can be considered useful:

1.      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 <>”.

2.      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.

3.      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.

4.      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.

5.      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.

What is Descriptive Programming

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. 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.

What is e-Commerce

What is e-commerce? 

For the purposes of this paper, e-commerce (also known as e-business) is defined as the software and business processes required to allow businesses to operate solely or primarily using digital data flows.  E-commerce is often associated with web technology and is commonly transacted via web portals, but e-commerce is much more than the provision of a web page as the customer interface.

    The creation of integrated business processes (Enterprise Resource Planning), the integration of collections of disparate software applications, each designed to facilitate a different aspect of the business (Enterprise Application Integration), the extension of software and business processes to embrace transactions with suppliers’ systems (Supply Chain Management), the need for increased security for transactions over public networks, and the potential volume demand at e-commerce sites all provide new and unique challenges to the e-commerce development community – challenges which will require novel and innovatory solutions and which will need thorough testing before they are allowed to go live.

Why is testing important in the e-commerce environment?

The first and primary reason is because e-commerce is, by its very nature, business critical.  In the third quarter of 1998, Dell’s e-commerce site exceeded $10 million in daily sales; the E*Trade site currently exceeds 52, 000 transactions per day, giving a cost of one-day failure of around $800,000; and the travel industry in Europe will be worth $2 billion by 2002, according to Datamonitor.  The immediacy of the customer, with its implied promise of rapid delivery at competitive prices, and the sheer accessibility of the web, all combine to create potentially massive demand on web sites and portals. 

The second reason is that e-commerce is a massive and growing market place but one which requires large up-front investment to enter successfully.  There are already 5.8 million web sites worldwide, 2.5 million of which have been created this year (1999).  The International Data Corporation (IDC) estimates that the e-commerce market will grow from over $5billion in 1998 to $1trillion in 2003.  The average cost of development of an e-commerce site is $1 million, says the Gartner Group and will increase by 25% annually over the next 2 years.

The third reason is because the history of e-commerce development has been littered with expensive failures, at least some of which could have been avoided by better testing before the site was opened to the general public.  (In e-commerce terms, ‘the site’ means the entire architecture from suppliers through back-end systems and front-end systems to the customers; it typically includes Intranet, Internet and extranet applications as well as legacy systems and third party middleware).

Ten Key Principles of Effective E-Commerce Testing

Over the decades since Information Technology (IT) became a major factor in business life, problems and challenges such as those now faced by the e-commerce community have been met and solved.  Key testing principles have emerged and these can be successfully applied to the e-commerce situation.

Principle 1.  Testing is a risk management process:  The most important lesson we have learned about software testing is that it is one of the best mechanisms we have for managing the risk to businesses of unsuccessful IT applications.  Effective testing adopts a strategy that is tailored to the type of application or service being tested, the business value of the application or service, and the risks that would accompany its failure.  The detailed planning of the testing and the design of the tests can then be conformed by the strategy into a business-focused activity that adds real business value and provides some objective assessment of risk at each stage of the development process.  Plans should include measures of risk and value and incorporate testing and other quality-related activities that ensure development is properly focused on achieving maximum value with minimum risk.  Real projects may not achieve everything that is planned, but the metrics will at least enable us to decide whether it would be wise to release an application for live use.

Principle 2.  Know the value of the applications being tested:  To manage risk effectively, we must know the business value of success as well as the cost of failure.  The business community must be involved in setting values on which the risk assessment can be based and committed to delivering an agreed level of quality.

Principle 3.  Set clear testing objectives and criteria for successful completion (including test coverage measures):  When testing an e-commerce site, it would be very easy for the testing to degenerate into surfing, due to the ease of searching related sites or another totally unrelated site.  This is why the test programme must be properly planned, with test scripts giving precise instructions and expected results.  There will also need to be some cross-referencing back to the requirements and objectives, so that some assessment can be made of how many of the requirements have been tested at any given time.  Criteria for successful completion are based on delivering enough business value, testing enough of the requirements to be confident of the most important behaviour of the site, and minimising the risk of a significant failure.  These criteria – which should be agreed with the business community - give us the critical evidence that we need in deciding readiness to make the site accessible to customers.

Principle 4.  Create an effective test environment:  It would be very expensive to create a completely representative test environment for e-commerce, given the variety of platforms and the use of the Internet as a communications medium.  Cross-platform testing is, naturally, an important part of testing any multi-platform software application.  In the case of e-commerce, the term ‘cross-platform’ must also extend to include ‘cross-browser’.  In order to ensure that a site loads and functions properly from all supported platforms, as much stress and load testing as possible should be performed.  As an absolute minimum, several people should be able to log into the site and access it concurrently, from a mixture of the browsers and platforms supported.  The goal of stress and load testing, however, is to subject the site to representative usage levels.  It would, therefore, be beneficial to use automated tools, such as Segue’s SilkPerformer or Mercury Interactive’s LoadRunner, for performance/load testing.

Principle 5.  Test as early as possible in the development cycle:  It is already well understood and accepted in the software engineering community that the earlier faults are detected, the cheaper the cost of rectification.  In the case of an e-commerce site, a fault found after shipping will have been detected as a failure of the site by the marketplace, which is potentially as large as the number of Internet users.  This has the added complication of loss of interest and possibly the loss of customer loyalty, as well as the immediate cost of fixing the fault.  The fact that e-commerce development is rapid and often based on changing requirements makes early testing difficult, but testing strategies have been developed by the RAD community, and these can be mobilised for support.   Perhaps the most important idea in RAD is the joint development team, allowing users to interact with the developers and validate product behaviour continuously from the beginning of the development process.  RAD utilises product prototypes, developed in a series of strictly controlled ‘timeboxes’ – fixed periods of time during which the prototype can be developed and tested – to ensure that product development does not drift from its original objectives.  This style of web development makes testing an integral part of the development process and enhances risk management throughout the development cycle.

Principle 6.  User Acceptance Testing (UAT):  The client or ultimate owner of the e-commerce site should perform field testing and acceptance testing, with involvement from the provider where needed, at the end of the development process.  Even if RAD is used with its continuous user testing approach, there are some attributes of an e-commerce site that will not be easy (or even possible, in some cases) to validate in this way.  Some form of final testing that can address issues such as performance and security needs to be included as a final confirmation that the site will perform well with typical user interactions.  Where RAD is not used, the scope of the provider’s internal testing coverage and user acceptance testing coverage should be defined early in the project development lifecycle (in the Test Plan) and revisited as the project nears completion, to assure continued alignment of goals and responsibilities. UAT, however, should not be seen as a beta-testing activity, delegated to users in the field before formal release.   E-commerce users are becoming increasingly intolerant of poor sites, and technical issues related to functionality, performance or reliability have been cited as primary reasons why customers have abandoned sites.  Early exposure of users to sites with problems increases the probability that they will find the site unacceptable, even if developers continue to improve the site during beta testing.

Principle 7.  Regression testing:  Applications that change need regression testing to confirm that changes did not have unintended effects, so this must be a major feature of any e-commerce testing strategy.  Web-based applications that reference external links need regular regression testing, even if their functionality does not change, because the environment is changing continuously. Wherever possible, regression testing should be automated, in order to minimise the impact on the test schedule.

Principle 8.  Automate as much as possible:  This is a risky principle because test automation is fraught with difficulties.  It has been said that a fool with a tool is still a fool, and that the outcome of automating an unstable process is faster chaos, and both of these are true.  Nevertheless, the chances of getting adequate testing done in the tight time scales for an e-commerce project and without automation are extremely slim.  The key is to take testing processes sufficiently seriously that you document them and control them so that automation becomes a feasible option – then you select, purchase and install the tools.  It will not be quick or cheap – but it might just avoid a very expensive failure.

Principle 9.  Capture test incidents and use them to manage risk at release time:  A test incident is any discrepancy between the expected and actual results of a test.  Only some test incidents will relate to actual faults; some will be caused by incorrect test scripts, misunderstandings or deliberate changes to system functionality.  All incidents found must be recorded via an incident management system (IMS), which can then be used to ascertain what faults are outstanding in the system and what the risks of release might be. Outstanding incidents can be one of the completion criteria that we apply, so the ability to track and evaluate the importance of incidents is crucial to the management of testing.

Principle 10.  Manage change properly to avoid undoing all the testing effort:  Things change quickly and often in an e-commerce development and management of change can be a bottleneck, but there is little point in testing one version of a software application and then shipping a different version; not only is the testing effort wasted, but the risk is not reduced either.  Configuration Management tools, such as PVCS and ClearCase, can help to minimise the overheads of change management, but the discipline is the most important thing.