Tuesday, 27 August 2013

Check all Links !!! QTP

systemutil.Run "firefox","http://argos.co.uk"
browser("title:=.*").page("title:=.*").Sync

Set li=description.Create()
li("html tag").value="A"
Set a=browser("title:=.*").page("title:=.*").ChildObjects(li)
msgbox a.count
'num=a.count
For i=0 to a.count-1
   'tag = a(i).GetROProperty("innertext")
   'href = a(i).GetROProperty("href")
   'Reporter.ReportEvent 0,  "Links in Page", "name:" & tag &  ";url: " & href
    'print a(i).GetROProperty("text")
    'print a(i).GetROProperty("href")
Set a = Browser("title:=.*").Page("title:=.*").ChildObjects(li)
ref = a(i).GetROProperty("href")
Browser("title:=.*").Page("title:=.*").link("text:=.*","index:="&i).click
Browser("title:=.*").sync
title1=Browser("title:=.*").getRoproperty("title")
MsgBox title1
Browser("title:=.*").navigate(ref)
'Navigates to the url taken from "href" property
Browser("title:=.*").sync
title2=Browser("title:=.*").getRoproperty("title")
'get the tile of the tNavigated page
MsgBox title2
If title1=title2 Then
'condition to check for the targetted page and Navigated page
Reporter.ReportEvent 0, "Navigated To Correct Page",""&title1
'Reports if correct
else
Reporter.ReportEvent 1,""&title1,""&title2
End If
Browser("title:=.*").back
'Navigates back to main page
Browser("title:=.*").sync
Next

Sunday, 25 August 2013

UFT API testing includes common XML activities that help you to test and verify XML.

A High-Level Overview of XML ,   XML stands for Extensible Markup Language, and is a specification for storing information. The World Wide Web Consortium describes XML as “a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.” When testing modern applications, we often find ourselves needing to handle Extensible Markup Language --XML. Testing XML requires the ability to parse, read , and dissect it and as we have seen in previous chapters many web services’s SOAP messages make use of XML. Like HTML, XML uses tags, but unlike HTML XML
has no tags of its own. The user creates whichever tags best describe the data he or she is dealing with. XML allows the user to create his or her own markup language. Unlike HTML, which is concerned with the presentation of data, XML was designed to address two other important areas: - Data Storage - Carrying Information UFT API testing includes common XML activities that help you to test and verify XML.
UFT API XML Activities There are five XML activities available to you under UFT API’s 
Toolbox: - Transform XML - transforms an XML file to another structure based on XSLT. 
 -Compare XMLs – performs a comparison between two XML strings.
 - String to XML - converts a string into an XML structure.
 - XML to string - converts an XML documents into a string.
 - Validate XML - validates an XML file against its XSD schema.
Before we can start using the XML activities, we’ll need to have an XML and XSD files to test against. For this we’ll use some sample XML found on ww.w3school.com’s web site.
UFT XML example files Before we get started, let’s create an XML file to work with. Rather than reinvent the wheel, we’ll simply use the shiporder.xml and the shiporder.xsd from w3school, which is a great web site that offers free tutorials on many web technologies, including XML. For this example we will also be using XSD, or XML Schema Definition, which uses XML elements and attributes to describe the structure of a custom markup language. Before we get started lets create some XML and XSD file that we will use in our UFT XML examples. Create an XML file 
1) Open up Notepad.
2) Navigate to: http:// www.w3schools.com/ schema/ schema_example.asp .
3) Highlight and copy the shiporder.xml and paste it into Notepad.
4) Save the file to a directory on your C drive as shiporder.xml. Your shiporder.xml should look like this:
<? xml version =" 1.0" encoding =" ISO-8859-1"? >
 < shiporder orderid =" 889923" xmlns:xsi =" http:// www.w3. org/ 2001/ XMLSchema-instance" xsi:noNamespaceSchemaLocation =" shiporder.xsd" >
 < orderperson > John Smith </ orderperson >
< shipto >
 < name > Ola Nordmann </ name >
< address > Langgt 23 </ address >
< city > 4000 Stavanger </ city >
 < country > Norway </ country >
</ shipto >
< item >
 < title > Empire Burlesque </ title >
 < note > Special Edition </ note >
 < quantity > 1 </ quantity >
 < price > 10.90 </ price >
 </ item >
 < item >
 < title > Hide your heart </ title >
 < quantity > 1 </ quantity >
 < price > 9.90 </ price >
 </ item >
</ shiporder >
Create an XSD file
 1) Open up Notepad.
2) Navigate to: http:// www.w3schools.com/ schema/ schema_example.asp .
3) Highlight and copy the shiporder.xsd and paste into Notepad.
4) Save the file to your C drive as shiporder.xsd Your shiporder.xsd should look like this:
 <? xml version =" 1.0" encoding =" ISO-8859-1" ?>
 < xs:schema xmlns:xs =" http:// www.w3. org/ 2001/ XMLSchema" >
< xs:element name =" shiporder" >
 < xs:complexType >
 < xs:sequence >
 < xs:element name =" orderperson" type =" xs:string"/ >
 < xs:element name =" shipto" >
 < xs:complexType > < xs:sequence >
< xs:element name =" name" type =" xs:string"/ >
 < xs:element name =" address" type =" xs:string"/ >
 < xs:element name =" city" type =" xs:string"/ >
 < xs:element name =" country" type =" xs:string"/ >
 </ xs:sequence > </ xs:complexType > </ xs:element >
< xs:element name =" item" maxOccurs =" unbounded" >
 < xs:complexType > < xs:sequence >
< xs:element name =" title" type =" xs:string"/ >
< xs:element name =" note" type =" xs:string" minOccurs =" 0"/ >
 < xs:element name =" quantity" type =" xs:positiveInteger"/ >
 < xs:element name =" price" type =" xs:decimal"/ >
 </ xs:sequence >
</ xs:complexType >
 </ xs:element >
 </ xs:sequence >
< xs:attribute name =" orderid" type =" xs:string" use =" required"/ >
</ xs:complexType >
 </ xs:element >
 </ xs:schema >
Validate XML Activity UFT’s has a Validate XML activity that allows a user to validate an XML document or XML string against an XML Schema Definition (XSD).
1) Create a new UFT API test named ValidateXML
2) In UFT, drag a File > Read from File activity onto the canvas.
3) Under Read from File Properties, set the following Input values:
  - File path = c:\ shiporder.xml
  - Encoding = Automatic
4) Drag an XML > Validate XML onto the canvas under Read from File.
5) Under Validate XML Properties, set the following Input values:
 - XML String = Click on the Link to data source. In the Select Link Source for XML string, point to the Read from File’s Content output property. Click OK.













- Import XSD to test folder = false
-XSD = C:\ shiporder.xsd

6) Run the test and look at the Run Results Viewer’s Validate XML Captured Date section. You should now see the message Validation ended successfully.







Tuesday, 20 August 2013

Brief About Automation!!!!

Introduction
Today software test automation is becoming more and more popular in both C/S and web environment. As the requirements keep changing (mostly new requirements are getting introduced on daily basis) constantly and the testing window is getting smaller and smaller every day, the managers are realizing a greater need for test automation. This is good news for us (people who do test automation). 
Benefits of Automation
Automated testing tools are capable of running continuously without any productivity loss or fatigue, with minimal or no manual intervention. This implies that organizations can plan testing activities beyond the traditional eight-hour work shift. This translates to a testing program that reduces the elapsed duration for testing by as much as two-thirds of the time required for manual testing.
Drivers
Direct Benefits
Indirect Benefits
People
Savings in staffing costs due to efficient redeployment of workforce
Motivated workforce, increased customer satisfaction
Process
Savings in testing lifecycle costs due to reduced execution time
Enhanced process efficiency, innovations
Technology
Improved productivity due to additional test cycles within a given schedule
Lower application lifecycle costs resulting from improved product quality

When should test Automation?
1)The test must be repeated
2)The test's 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) When there are frequent regression testing iterations
5)The test produces results for a regulatory body that demands that those results be electronically recorded and archived as formal evidence of compliance
6)The test's pass/fail results are reasonably easy to determine and capture with selected automation tool
When should Test Automation Be Avoided?
1)In the case of Adhoc testing where subject matter expert randomly prowls through a variety of combination work flows
2)In the case of onetime testing or when is repeated only 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  functionality
4)Testing where look and feel ,color table lay out et..are validated
5)Test cases for which test data cannot be determined before hand
selecting any testing tool:
Anyone who has contemplated the implementation of an automated test tool has quickly realized the wide variety of options on the market in terms of both the kinds of test tools being offered and the number of vendors. The best tool for any particular situation depends on the system engineering environment that applies and the testing methodology that will be used, which in turn will dictate how automation will be invoked to support the process.
1) Do you have necessary skilled resource to allocate for automation tasks?
2) What is your budget?
3) Easy to maintain automated tests with a central repository whereby users can separate GUI object definitions from the script
4) Does the tool satisfy your testing needs? Is it suitable for the project environment and technology you are using? Does it support all tools and objects used in the code? Sometime you may get stuck for small tests due to inabilities of the tool to identify the objects used in the application.
5) Does the tool provide you the free trial version so that you can evaluate it before making a decision? Also does the tool have all features available in trial version?
6) Does it provide simple interface yet powerful features to accomplish complex tasks?
7)  Does it integrate well with your other testing tools like project planning and Test management tools
8) How is the tool learning curve? Is the learning time acceptable for your goals?
Costs of Automation
The cost elements for automation can be classified as fixed and recurring costs. Fixed costs are one time investments that are needed initially to establish the automation environment. Recurring costs are incurred during the testing lifecycle. The cost matrix depicts the distribution of fixed and recurring costs across people, process and technology drivers.

Drivers
One Time Costs
Recurring Costs
People

 Cost of training staff on automation tools
 Staffing costs for automation script development

Staffing costs for automation script maintenance
Process

 Costs for establishing new processes (workflow, configuration management, process management and so on)

Not Applicable
Technology

 Cost of hardware and software
Licenses for automation

Cost of maintaining hardware and automation software

What is Framework?
Automation Frameworks can provide reusable code bases which support the deployment of the testing tool into the engagement.
Types of Frameworks?
            1.Test Script Modularity
            2.Test Library Architecture
            3.Data-Driven Testing
            4.Keyword-Driven or Table-Driven Testing
            5.Hybrid Test Automation
Benefits Of Framework?
                 1. Reduce testing time.
                 2. Improve testing productivity.
                 3. Improve product quality
                 4. Reduce QA costs.
                 5. Consistent test results.
                 6. Schedule test run  7.Re-use

Observations
I have met a number of QA and Test managers who are frustrated with their automation. According to them the tool is not doing what it is supposed to do. Here is a true story, the client (I had the opportunity to work with them for some time) found out that the tool they have just bought does not support the application they are testing (I am not making it up). How can this happen! – It does happen more often than one would think. I will get back on this when I discuss possible solutions. A manager of one of the major telecom companies that I had a recent interview with told me that after three years and more than a million dollar he is still struggling with automation. This is pretty sad and I get the feeling that he is not alone.
Solutions/Suggestions
Let’s discuss some of the reasons for this frustration and some of the solutions to this problem.

Unrealistic expectations: Most managers have their first encounter with any automation tool when they look at the demo and everything looks nice and simple.But everything is not so nice and simple when you try to use the tool with your application. The vendors will only tell you the things you want to hear (how easy to use, how simple to set up, how it will save time and money, how it will help you find more bugs etc.). This builds a false set of hopes and expectations.
Lack of planning: A great deal of planning is required from selection to implementation of the tool. “Evaluating Tools” by Elisabeth Hendrickson is a very good article on step by step process of selecting a tool. She talks about “Tool Audience” as one of the steps. This would be an ideal way to select a tool. It may not happen in every place because of the everyday workload of the people involved. But the participation of the users in the process is very important, because they are the ones who will use the tool day in and day out. I am almost certain that what happened to one of my clients (the tool they have bought did not support the application they were testing) would not have happened if the users were involved in the selection process. 
Lack of a process: Lack of a process may also contribute to failure of automation. Most places do have some kind of process in place. In most cases (although it differs from place to place) developers write code against a set of requirements. If the requirement does not call for a change in GUI then, there should not be any change in GUI. But if the GUI keep changing constantly from one release to another without any requirement for that change then, there is a problem in the process. You may have the best tool and the best (for your environment) architecture is in place and you will still have problems with your automation because of a faulty process.
Conclusion
I think there is a need to educate  managers about the benefits and limitations of automation. There is a need to separate the facts from the fictions. But here is the problem, in most cases consultants are brought in to fix problems of prior attempts instead of initial setup. At this point the managers have already learned (painfully) the pitfalls of automation. In order to avoid this painful experience I would recommend (most automation engineers will agree with me) to spend more time up front doing research about the styles and techniques of automation and find an architecture that fits the environment. There is no doubt that automation adds a great value to overall QA process but, short of knowledge and understanding about automation and lack of planning can also cause a nightmare.

Sudhakar.Mangi