Automation Project Management and Automation Architecture

Automation Project Management and Automation Architecture

Introduction
Numerous white papers and articles are written on test automation. Most are well researched and present a wide range of views about the benefits of using automation. Some of the articles are the collection of individual experiences (some are more painful than others) to make the automation work for them. In this paper, I would like to discuss automation from project management and architecture standpoint and hope this may help others to establish a process that fit their testing environment.

Since a great deal of important information is already available on cost/benefit analysis of automation, I will not attempt to engage in further discussion on this. But I will say that it is very important to do a cost/benefit analysis of the test cases that require automating. James Hancock wrote: “When to Automate Testing - A Cost-Benefit Analysis” which is an excellent article on this subject.

Along with the cost/benefit analysis, detail planning must be completed. I concur with the experts that a great deal of planning is necessary before jumping onto this "automation boat". If omitted, the testing journey could be very rough and possibly cause the fatality of the project. I was involved in a project where a good deal of time was spent debugging existing test scripts because minor changes were made to the Application Under Test (AUT). A small change in the application should not require a great deal of maintenance. I like to discuss the followings and will try to shed some light on the subject.

- Automation Project Management
- Automation Architecture

Automation Project Management
Since automation is like a development environment, it should be treated like one. Keeping this in mind, let’s discuss some of the criteria of putting together an automation project team. At this point, let’s assume that the cost/benefit analysis is completed and the pay back period has been determined. Since this is a Quality Assurance (QA) project, it is recommended that the project leader comes from QA or understands QA and automation. I will discuss later in this section the danger (so to speak) of having a project leader with very little or no knowledge of Q.A. (particularly test automation). Once the project leader is selected, the selections of team members follow.

Below are typical skills necessary for the members of an automation team.

- Development (Programming) skill
- Knowledge of the test script language (familiar with C syntax if you are using Mercury
automated test tools WinRunner and XRunner; familiar with VB syntax if you are using SQA
suite products)
- Ability to write and execute a test plan.

Let’s talk about these skill sets in some detail. Many test automation tool vendors will like you to believe that using their tool is so easy that a person with no programming skill should be able to do automation in no time. They are of course referring to Record/Playback feature of their test tool. In our discussion, let’s assume that Record/Playback is not a viable option of automation and I think we all know why (lack of reusable code). Record/Playback is acceptable if you are planning on using the script for a very short period of time. I personally think that it is nice to have this feature, but I will not use it unless I have exhausted all other means. This leaves us with the option to write test scripts programmatically. Familiarity with the test script language is also important. There is a learning curve for someone who does not have a prior experience with a particular test tool. Finally, an automation engineer will have to have prior experience of writing and executing test cases, because automation is no more than automating the existing manual test cases.

It is also important to select an automation lead person from the members. A lead person should have prior experience with the tool. If any of the members do not have prior experience, then my suggestion would be to hire a consultant who has an extensive scripting experience (no Record/Playback) with that particular test tool. A word of caution while selecting a consultant to be your automation lead - ask a lot of questions about their previous projects. For example, what were some of the problems they had to face and how did they get around it; what kind (if any) of architecture was in place? If you don’t have enough knowledge about the product or automation, get someone who does, because this lead person can make or break your project. It is a good idea to hire someone from a reputable consulting firm even if it costs more money. You probably discovered during the cost/benefit analysis that the biggest part of the automation cost is labor and not the product. It is worth paying big bucks to consultants to set up automation the right way. The alternative is poor setup with no architecture and no standards, which causes a lot maintenance headache down the road, turnover in the automation team, and eventually the abandonment of the automation. This is one of the dangers of having a project leader with little or no knowledge of test automation.
After selecting the project leader and the team members, our team is in place. At this point we are ready to do the design.

Automation Architecture

“Improving the Maintainability of Automated Test Suites” by Cem Kaner is an excellent article where he talks about two different architectures, Data-driven architecture and Framework-based architecture as two viable options for automation. My design supports, for most part, the Framework-based architecture. The followings are the components of this architecture,

- Main Routine
- Environment Setup
- Screens Navigation
- Test Data

Main Routine
I like to call this the “Engine” of the architecture, because it drives the body. Here the engineers will organize the steps of execution. I will come back to this and explain what I mean by organization of steps. Here you can do the necessary environment setups, open output file/files, load and unload compiled modules. At the end, close the output file/files.

Environment Setup
In this section, you can set up the necessary system variables (speed, fonts etc.). Declaring global variables can also be a part of the environment set up. You can also call Common_Lib (a common library of reusable functions) in this section. The functions in the common library are reused over and over again by everybody in the automation team throughout the existence of automation. This can be dynamic and additional user defined functions can be added to the library as needed.

Example of reusable functions:

- Opening and closing of the output files
- Drag and drop of an object (location parameter driven - change the parameter according to the location of the object need to be dragged and dropped)
- Status Check (location parameter driven - change the parameter according to the location of the status bar on the screen)
- Single mouse Click (location parameter driven - change the parameter according to the location of the objects need to be clicked)
- Double mouse click (location parameter driven - change the parameter according to the location of the objects need to be double clicked).

Screens Navigation
The purpose of this section is to navigate through a screen using a number of user-defined functions. It can be done many different ways and it is up to the engineers to decide the best way for their environment. In most cases, engineers write one function per screen. I prefer writing a number of small and simple functions for each field on the screen instead of writing one big function per screen.

For example, let’s assume we have a screen called “New Customer” with the following edit fields and push buttons:

- Customer name
- Street address
- City
- State
- Zip
- Telephone number
- Enter
- Cancel

I would write functions for each edit field and a single mouse click function for push buttons to navigate through the “New Customer” screen.

Below are some examples (Test script language for WinRunner and XRunner),

# Inserts customer name
function Cust_Name(in cust_name)
{
Type_Text(cust_name);
return;
}

# Inserts customer address(Street, City, state and zip)
function Cust_Street(in st_addr)
{
Type_Text(st_addr);
return;
}
function Cust_City(in city)
{
Type_Text(city);
return;
}

function Cust_State(in state)
{
Type_Text(state);
return;
}

function Cust_Zip(in zip)
{
Type_Text(zip);
return;
}

# Inserts customer telephone number
function Tel_Phone(in ph_no)
{
Type_Text(ph_no);
return;
}

# Clicks button (Right or left mouse click)
function Click_Button(in loc1, in loc2, in loc3, in button)
{
if (!button)
button = 0;
move_locator_abs (loc1, loc2, loc3);
if (button==0)
click("Left");
else if (button==1)
click("Right");
return;
}

There are two advantages to use this over writing one function per screen. First, these are small and simple which makes maintenance easy and quick. But the biggest advantage is the code is reusable. If you have other screens that require customer name, address and telephone number, you should be able to use the same code with different test data.

Test data
This is a separate test script contains test data which are used to populate the edit fields. These are one-dimensional arrays. Below are some examples:

public test_data [] = {
"Cust_Name" = {"John Doe"},
"Cust_Street" = {"1234 Main street"},
"Cust_City" = { "Dallas"},
"Cust_State" = {"Tx"},
"Cust_Zip" = {"75240"},
"Tel_Phone" = {"972-221-1212"}
};

You may have a small or a large number of test data depending upon the nature of the test you are performing. It is better to have a large number of test data than a large number of test scripts because it is easier to maintain test data than test scripts.

Automation is easy if you have to navigate through the same screen with different test data. In our example above, we can easily automate a test case that checks to see the maximum number of customers can be created (boundary test). In this case we will use the same code over and over with a different set of test data. But in most cases, it requires the use of different set of code with a different set of test data. This is where the organization of steps comes in.

The following scenario may help you to understand,
Let’s say in order to automate a test case (create a customer) you need to navigate through three different screens with different edit fields and they are in following order:

- New Customer (Customer name, Street address, City, State, Zip, Telephone)
- Contact Information (Contact name, Street address, City, State, Zip, Telephone)
- Bank information (Bank name, Street address, City, State, Zip, Telephone)

First of all we need a number of Test Data for these edit fields. We will follow above example (one-dimensional arrays) to set up the test data.
We then need to write a number of user defined functions to navigate through these screens (Screens Navigation). You may want to either write a single function for each screen or write a number of small functions for each edit field in the screen. I found the later more useful.
Test data and all the functions written in Screens Navigation are compiled modules. The advantage of using compiled modules over regular test scripts is that execution of compiled modules is faster. But loading too many compiled modules also causes performance degradation. So, it is a good idea to unload each compiled module after the execution of that module.
The organization is usually done in Main Routine. In Main Routine we will,
- Call the test script to set up the environment
- Load compiled modules
- Open output files
- Call the first test script (let’s call it ‘Create_Customer’)
If no error run New_Customer(1) à indexed (pointing to a particular set of test data) from ‘Create_Customer’ test script.
If no error run Contact_Information(2) à indexed (pointing to another set of test data) from ‘New_Customer’ test script.
If no error run Bank_Information(3) à indexed (pointing to another set of test data) from ‘Contact_Information’ test script.
- Unload Common library
- Unload compiled modules
- Close output files

. One could make the following arrangement in Main Routine,
- Call the test script to set up the environment
- Load compiled modules
- Open output files
- Call the first test script (Create_Customer)
- If no error
- {
Run New_Customer(1)
If no error
{
Run Contact_Information(2)
If no error
{
Run Bank_Information(3)
}
}
}

- Unload Common library
- Unload compiled modules
- Close output files

In both cases if there is an error, print the appropriate error message to the output file and exit out of that particular routine. While writing results to an output file, it probably is a good idea to have enough information (eg: Test case number, Test case objective, Objective of a particular step etc.) so that in case of a “Fail” status you will know exactly where to look in your test scripts. This helps a great deal in debugging the test scripts.

Conclusion
If this seems like a lot of work, it is. It takes time to set up architecture, but once the standard and the architecture is in place, the subsequent development time is considerably shorter. This architecture may not suit every environment, because it requires test engineers to have some degree of programming skill. I don’t know any effective automation process that does not require some degree of programming skill. The best part of this architecture is more reusability and less maintenance. Reusability and maintainability go hand in hand. The more code can be reused the less code need to be written and less the code, less the maintenance. One thing to remember is that reusability and complexity (complexity of code) also go hand in hand. The more reusability you want the more complex code you need to write. It is not always easy to maintain a complex set of code when you don’t have skilled personnel. The reality is you are probably not going to find a large number of testers who have sophisticated programming skill. So, it is safe to suggest writing simple code such that a person with little programming skill can maintain these scripts fairly easily.

NOTE: I have written this paper based on my experience with a number of automation projects I was associated with. There is no one way to do automation. Every project is different and every place has their own way of doing things. I have found this particular architecture seems to work provided you have skilled personnel and the management who understands and supports the process. It is not to say that other form of architecture or Record and Playback will not work. No matter what form of architecture you decide to work with make sure that most everybody in the group is comfortable with it, because it is the people (not the tool[tool helps]) makes a product as good as it can be(or in most cases as market allows it to be).

---Chandra. By "M.N. Alam"

Sample QTP Scripts..

1. To Count and display Object Properties and Values

Dim Obj1,ObPrp

Set Obj1=Window ("Flight Reservation")
Set ObPrp=Obj1.GetToProperties
For i=0 To ObPrp.Count -1
msgbox i+1 & " - " & ObPrp(i).Name & " ....... “& ObPrp(i).Value
Next

2 . Login Verification with constant input values

InvokeApplication "C:\Program Files\Mercury Interactive\QuickTest
Professional\samples\flight\app\flight4a.exe"

Dialog("Login").WinEdit("Agent Name:").Set "Jampani"
Dialog("Login").WinEdit("Password:").Set "Mury"
Dialog("Login").WinButton("OK").Click

If Dialog("Login").Dialog("Flight Reservations").Exist Then
Dialog("Login").Dialog("Flight Reservations").WinButton("OK").Click
Dialog("Login").WinButton("Cancel").Click
Reporter.ReportEvent 1,"Login Verify","Invalid Values...Test Failed"
Else
Window("Flight Reservation").WinMenu("Menu").Select "File;Exit"
Reporter.ReportEvent 0,"Login Verify","Valid Inputs...Test Passed"
End If

3. Login Verification with Runtime Input Values

Dim Flights,Agt,Pwd

Flights="C:\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\flight4a.exe"

For i=1 To 4
Agt=InputBox("Enter Agent Name Plzzz")
Pwd=InputBox("Enter PAssword ..Plzzz")
InvokeApplication Flights
Dialog("Login").WinEdit("Agent Name:").Set Agt
Dialog("Login").WinEdit("Password:").Set Pwd
Dialog("Login").WinButton("OK").Click

If Dialog("Login").Dialog("Flight Reservations").Exist Then
wait(3)
Dialog("Login").Dialog("Flight Reservations").WinButton("OK").Click
wait(3)
Dialog("Login").WinButton("Cancel").Click
Reporter.ReportEvent 1,"Login","Test Failed"
Else
Window("Flight Reservation").WinMenu("Menu").Select "File;Exit"
Reporter.ReportEvent 0,"Login","Test Passed"

End If

Next

4. Login with Parameterization ... Data Table (Global Sheet) Should contain Values

SystemUtil.Run "C:\Program Files\Mercury Interactive\QuickTest

Professional\samples\flight\app\flight4a.exe","","C:\Program Files\Mercury Interactive\ QuickTest Professional\samples\flight\app\","open"

'InvokeApplication "C:\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\flight4a.exe"

Dialog("Login").WinEdit("Agent Name:").Set DataTable("Agent_Name", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Pword", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click

If Dialog("Login").Dialog("Flight Reservations").Exist Then
Dialog("Login").Dialog("Flight Reservations").WinButton("OK").Click
Dialog("Login").WinButton("Cancel").Click
Reporter.ReportEvent 1,"Login Verify","Invalid Values...Test Failed"
DataTable.Value("Act_Res")="Fail"
Else
Window("Flight Reservation").WinMenu("Menu").Select "File;Exit"
Reporter.ReportEvent 0,"Login Verify","Valid Inputs...Test Passed"
DataTable.Value("Act_Res")="Pass"
End If

er=DataTable("Exp_Res",dtGlobalSheet)
ar=DataTable("Act_Res",dtGlobalSheet)

If StrComp(er,ar)=0 Then
DataTable.Value("Remarks")="OK"
Else
DataTable.Value("Remarks")="Defect"
End If
DataTable.Export("E:\QTP730\LoginResults.xls")

Descriptive programming for DataDrivenTesting using Notepad

Descriptive programming for DDT using Notepad
QTP Script

Set f=createobject("scripting.filesystemobject")
Set f1=f.createtextfile("d://DDT1.txt")
f1.writeline"aaa bbb"
f1.writeline"ccc ddd"
f1.writeline"eee fff"
f1.writeline"ggg hhh"
f1.writeline"iii jjj"

The above script creates a notepad in "d" drive with name DDT1
aaa bbb
ccc ddd
eee fff
ggg hhh
iii jjj

values are stored in DDT1.txt.

Set f2=f.opentextfile("d://DDT1.txt")
While f2.atendofstream<>true
f3=f2.readline
x=split(f3," ")
msgbox x(0)
msgbox x(1)
Wend

The above script is used for data driven using notepad directly.here we are not importing data to excel sheet.
directly values are retreived from notepad.

we are using while loop and reading each line till the end.
split function splits the line where space(" ")occurs.
line is divided to 2 parts.one before space and other after space
for example we have 1st line in notepad as aaa bbb

here aaa is 1st part and bbb is 2nd part
x(0)=aaa
x(1)=bbb

all values are read this way using while loop.
One point to note here is if any line is empty in notepad datadriven testing is stopped before that line.
It will not proceed further.so we have to give values without any empty lines in notepad.
to make u more clear
suppose u have
aaa bbb

ccc ddd
datadriven is stopped at aaa and bbb only because next line is empty.datadriven is stopped after 1st line.

QTP Tips..

How can i check if a checkpoint passes or not?
check_PassFail = Browser(...).Page(...).WebEdit(...).Check (Checkpoint("Check1"))
if check _PassFail then
MsgBox "Check Point passed"
else
MsgBox "Check Point failed"
end if

How to add a constant number in a datatable?
This is more to do with MS excel then WinRunner / QTP.If add number to the Excel sheet, it will take default format. If you add ‘ to the number it will become constant.
Ex: if you wish to enter 1234567 in datatable then write it as '1234567

How can i check if a parameter exists in DataTable or not?
The best way would be to use the below code:
on error resume next
val=DataTable("ParamName",dtGlobalSheet)
if err.number<> 0 then
'Parameter does not exist
else
'Parameter exists
end if

QTP Script for connecting to database

Script for connecting to MS Access.

Option Explicit
Dim con,rs
Set con=createobject("adodb.connection")
Set rs=createobject("adodb.recordset")
con.provider="microsoft.jet.oledb.4.0"
con.open"d:\testdata.mdb"
rs.open"select*from emp",con
Do while not rs.eof
VbWindow("Form1").VbEdit("val1").Set rs.fields("v1")
VbWindow("Form1").VbEdit("val2").Set rs.fields("v2")
VbWindow("Form1").VbButton("ADD").Click
rs.movenext
Loop

Database we are using here is MS-Access, before running this script create a table in MS Acess.
In the above script i used table called "emp" and column names as "v1" and "v2".
"d:\testdata.mdb" is path of the table which we created in MS Access.
Main use of this application is to use testdata of table(which is in database) in the application.

Script for connecting to sqlserver

Option Explicit
Dim con,rs
Set con=createobject("adodb.connection")
Set rs=createobject("adodb.recordset")

con.open"provider=sqloledb.1;server=localhost;uid=sa;pwd=;database=testdata"
rs.open"select*from emp",con

Do while not rs.eof
VbWindow("Form1").VbEdit("val1").Set rs.fields("v1")
VbWindow("Form1").VbEdit("val2").Set rs.fields("v2")
VbWindow("Form1").VbButton("ADD").Click
rs.movenext
Loop

Script for connecting to oracle
Option Explicit
Dim con,rs
Set con=createobject("adodb.connection")
Set rs=createobject("adodb.recordset")

con.open"provider=oraoledb.1;server=localhost;uid=scott;pwd=tiger;database=testdata"
rs.open"select*from emp",con

Do while not rs.eof
VbWindow("Form1").VbEdit("val1").Set rs.fields("v1")
VbWindow("Form1").VbEdit("val2").Set rs.fields("v2")
VbWindow("Form1").VbButton("ADD").Click
rs.movenext
Loop

QTP FAQ's Basik

Automated Testing Using Quick Test Professional
--chandra
http://www.youtube.com/watch?v=I_ZmdcDnzEw&feature=related

QuickTest Professional (QTP)
PowerTest can help you evaluate, purchase and implement QuickTest Professional (QTP).
QuickTest Professional (QTP) by HP is a fresh approach to automated software and application testing that addresses testing needs of both business analysts and Quality Assurance professionals. QuickTest Professional is the result of a dozen years of automated testing solution development experience and is designed to provide a robust application verification solution without the need for advanced technical or programming expertise. By using QuickTest Professional, organizations can:
Keep pace with fast-changing technologies with maintainable testing solutions.
Verify the functionality of integrated, multi-environment enterprise solutions.
Minimize the time and effort required to develop a powerful test suite.
Reduce training time and increase QA productivity.
Practice collaborative testing to leverage existing Quality Assurance resources and best practices across the enterprise.
Integrate with WinRunner, LoadRunner, and TestDirector for Qulity Center

Features & Benefits
Ensures an immediate return on investment through its ease of use
QuickTest Professional's integration of ActiveScreen, TreeView and the Data Table ensures that minimal time and effort are required for developing a powerful test suite and obtaining immediate results. As a result, even novice testers are productive as soon as they start using the tools.

Enables script maintainability and increased efficiency
QuickTest Professional supports full flexibility of the test script to handle changes in the objects, in the tested application’s GUI and in the testing environment. Test scripts are reusable throughout an application’s lifecycle.

Facilitates collaboration among testing groups
By using QuickTest Professional, testers can access a centralized repository and easily share actions, functions and test scripts across the network and enterprise.

Enables testing of mixed environments and applications
QuickTest Professional provides a multifunctional solution for testing dynamically changing Web, Java, ERP/CRM and multimedia content across environments.

Leverages investments in other automated testing tools
Mercury Interactive's WinRunner functional testing tool and TestDirector test management product both integrate with QuickTest Professional. QuickTest Professional can launch WinRunner to execute TSL test scripts and view the results of those scripts. By doing so, companies can leverage their existing WinRunner TSL script and function libraries. Furthermore, QuickTest Professional can store its scripts and test results in TestDirector, enabling an entire QA and development team to effectively collaborate to improve application quality.

ReporterManager allows you to easily set up any combination of reporters, set complex rules for each and every reporter, and immediately use them in your scripts. After setting the reporters once, using the mechanism boils down to one simple command: oReporterManager.Report. You can choose from (so far) 7 reporting engines - User timed popup message, Excel, Styled Text, Screen Capture, Windows event log reporter (local or remote), DB reporter and the native QTP reporter. You can and apply as many Regular-Expression and Object-State filters on them as you’d like. Aside from the current engines and filters, ReporterManager can be easily extended to include countless more reporting and filtering techniques. Just use the included class template to easily create engines and filters that suite your needs. To illustrate ReporterManager’s strength - with ReporterManager you can:
1. Set up a text backup log (in case QTP will crash and the results will be lost forever), styled for convenient reading.
2. Set up a special text Error log (which only includes failed steps), for quick skimming, and save pictures of all the errors.
3. Set up a fancy Excel log, which only logs performance timers. And you can do all that with just 10 code lines

Which scripting language used by QTP ?
QTP uses VB scripting.
What’s the basic concept of QTP ?
QTP is based on two concept-* Recording* PlaybackHow many types of recording facility are available in QTP ?
QTP provides three types of recording methods-* Context Recording (Normal)* Analog Recording* Low Level Recording
How many types of Parameters are available in QTP ?
QTP provides three types of Parameter-* Method Argument* Data Driven* Dynamic
What’s the QTP testing process ?
QTP testing process consist of seven steps-* Preparing to recoding* Recording* Enhancing your script* Debugging* Run* Analyze* Report Defects
What’s the Active Screen ?
It provides the snapshots of your application as it appeared when you performed a certain steps during recording session.
What’s the Test Pane ?
Test Pane contains Tree View and Expert View tabs.
What’s Data Table ?
It assists to you about parameterizing the test.
What’s the Test Tree ?
It provides graphical representation of your operations which you have performed with your application.
Which all environment QTP supports ?
ERP/ CRMJava/ J2EEVB, .NETMultimedia, XMLWeb Objects, ActiveX controlsSAP, Oracle, Siebel, PeopleSoftWeb Services, Terminal EmulatorIE, NN, AOL
How can you view the Test Tree ?
The Test Tree is displayed through Tree View tab.
What’s the Expert View ?
Expert View display the Test Script.
Which keyword used for Nornam Recording ?
F3
Which keyword used for run the test script ?
F5
Which keyword used for stop the recording ?
F4
Which keyword used for Analog Recording ?
Ctrl+Shift+F4
Which keyword used for Low Level Recording ?
Ctrl+Shift+F3
Which keyword used for switch between Tree View and Expert View ?
Ctrl+Tab
What’s the Transaction ?
You can measure how long it takes to run a section of your test by defining transactions.
Where you can view the results of the checkpoint ?
You can view the results of the checkpoints in the Test Result Window.
What’s the Standard Checkpoint ?
Standard Checkpoints checks the property value of an object in your application or web page.
Which environment are supported by Standard Checkpoint ?
Standard Checkpoint are supported for all add-in environments.
What’s the Image Checkpoint ?
Image Checkpoint check the value of an image in your application or web page.
Which environments are supported by Image Checkpoint ?
Image Checkpoint are supported only Web environment.
What’s the Bitmap Checkpoint ?
Bitmap Checkpoint checks the bitmap images in your web page or application.
Which environment are supported by Bitmap Checkpoints ?
Bitmap checkpoints are supported all add-in environment.
What’s the Table Checkpoints ?
Table Checkpoint checks the information with in a table.
Which environments are supported by Table Checkpoint ?
Table Checkpoints are supported only ActiveX environment.
What’s the Text Checkpoint ?
Text Checkpoint checks that a test string is displayed in the appropriate place in your application or on web page.
Which environment are supported by Test Checkpoint ?
Text Checkpoint are supported all add-in environments
Note:
* QTP records each steps you perform and generates a test tree and test script.
* QTP records in normal recording mode.
* If you are creating a test on web object, you can record your test on one browser and run it on another browser.
* Analog Recording and Low Level Recording require more disk sapce than normal recording mode.

--Page:2--

1) What is QTP ?
A) QuickTest is a graphical interface record-playback automation tool. It is able to work with any web, java or windows client application. Quick Test enables you to test standard web objects and ActiveX controls. In addition to these environments, QuickTest Professional also enables you to test Java applets and applications and multimedia objects on Applications as well as standard Windows applications, Visual Basic 6 applications and .NET framework applications...

2) Explain QTP Testing process ?
A) The QuickTest testing process consists of 6 main phases:

Create your test plan

Prior to automating there should be a detailed description of the test including the exact steps to follow, data to be input, and all items to be verified by the test. The verification information should include both data validations and existence or state verifications of objects in the application.

Recording a session on your application
As you navigate through your application, QuickTest graphically displays each step you perform in the form of a collapsible icon-based test tree. A step is any user action that causes or makes a change in your site, such as clicking a link or image, or entering data in a form.Enhancing your testInserting checkpoints into your test lets you search for a specific value of a page, object or text string, which helps you identify whether or not your application is functioning correctly.

NOTE: Checkpoints can be added to a test as you record it or after the fact via the Active Screen. It is much easier and faster to add the checkpoints during the recording process.

Broadening the scope of your test by replacing fixed values with parameters lets you check how your application performs the same operations with multiple sets of data.Adding logic and conditional statements to your test enables you to add sophisticated checks to your test.

Debugging your test
If changes were made to the script, you need to debug it to check that it operates smoothly and without interruption.
Running your test on a new version of your applicationYou run a test to check the behavior of your application. While running, QuickTest connects to your application and performs each step in your test.

Analyzing the test results
You examine the test results to pinpoint defects in your application.

Reporting defects

As you encounter failures in the application when analyzing test results, you will create defect reports in Defect Reporting Tool.

3) Explain the QTP Tool interface.
A)It contains the following key elements:
Title bar, displaying the name of the currently open testMenu bar, displaying menus of QuickTest commandsFile toolbar, containing buttons to assist you in managing testsTest toolbar, containing buttons used while creating and maintaining testsDebug toolbar, containing buttons used while debugging tests.
Note: The Debug toolbar is not displayed when you open QuickTest for the first time. You can display the Debug toolbar by choosing View > Toolbars > Debug. Note that this tutorial does not describe how to debug a test.
Action toolbar, containing buttons and a list of actions, enabling you to view the details of an individual action or the entire test flow.
Note: The Action toolbar is not displayed when you open QuickTest for the first time. You can display the Action toolbar by choosing View > Toolbars > Action. If you insert a reusable or external action in a test, the Action toolbar is displayed automatically.

Test pane, containing two tabs to view your test-the Tree View and the Expert View, Test Details pane, containing the Active Screen

Data Table, containing two tabs, Global and Action, to assist you in parameterizing your test.

Debug Viewer pane, containing three tabs to assist you in debugging your test-Watch Expressions, Variables, and Command. (The Debug Viewer pane can be opened only when a test run pauses at a breakpoint.)

Status bar, displaying the status of the test.

4) What is keyword view and Expert view in QTP?
A) QuickTest’s Keyword Driven approach, test automation expertshave full access to the underlying test and object properties, via anintegrated scripting and debugging environment that is round-tripsynchronized with the Keyword View.Advanced testers can view and edit their tests in the Expert View,which reveals the underlying industry-standard VBScript thatQuickTest Professional automatically generates. Any changesmade in the Expert View are automatically synchronized with theKeyword View.

5) Explain about the Test Fusion Report of QTP ?
A) Once a tester has run a test, a TestFusion report displays allaspects of the test run: a high-level results overview, an expandableTree View of the test specifying exactly where application failuresoccurred, the test data used, application screen shots for every stepthat highlight any discrepancies, and detailed explanations of eachcheckpoint pass and failure. By combining TestFusion reports withQuickTest Professional, you can share reports across an entire QAand development team.

6) To which environments does QTP supports ?
A) QuickTest Professional supports functional testing of all enterpriseenvironments, including Windows, Web, ..NET, Java/J2EE, SAP,Siebel, Oracle, PeopleSoft, Visual Basic, ActiveX, mainframeterminal emulators, and Web services.

7) How QTP recognizes Objects in AUT?
A) QuickTest stores the definitions for application objects in a file called the Object Repository. As you record your test, QuickTest will add an entry for each item you interact with. Each Object Repository entry will be identified by a logical name (determined automatically by QuickTest), and will contain a set of properties (type, name, etc) that uniquely identify each object.Each line in the QuickTest script will contain a reference to the object that you interacted with, a call to the appropriate method (set, click, check) and any parameters for that method (such as the value for a call to the set method). The references to objects in the script will all be identified by the logical name, rather than any physical, descriptive properties.

8) What are the types of Object Repositorys in QTP?
A) QuickTest has two types of object repositories for storing object information: shared object repositories and action object repositories. You can choose which type of object repository you want to use as the default type for new tests, and you can change the default as necessary for each new test.The object repository per-action mode is the default setting. In this mode, QuickTest automatically creates an object repository file for each action in your test so that you can create and run tests without creating, choosing, or modifying object repository files. However, if you do modify values in an action object repository, your changes do not have any effect on other actions. Therefore, if the same test object exists in more than one action and you modify an object's property values in one action, you may need to make the same change in every action (and any test) containing the object.

9) Explain the check points in QTP?
A)A checkpoint verifies that expected information is displayed in a Application while the test is running. You can add eight types of checkpoints to your test for standard web objects using QTP.A page checkpoint checks the characteristics of a ApplicationA text checkpoint checks that a text string is displayed in the appropriate place on a Application.An object checkpoint (Standard) checks the values of an object on a Application.An image checkpoint checks the values of an image on a Application.A table checkpoint checks information within a table on a ApplicationAn Accessiblity checkpoint checks the web page for Section 508 compliance.An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application.A database checkpoint checks the contents of databases accessed by your web site.

10) In how many ways we can add check points to an application using QTP.
A) We can add checkpoints while recording the application or we can add after recording is completed using Active screen (Note : To perform the second one The Active screen must be enabled while recording).

11) How does QTP identifes the object in the application.
A) QTP identifies the object in the application by LogicalName and Class.For example :The Edit box is identified byLogical Name : PSOPTIONS_BSE_TIME20Class: WebEdit.

12) If an application name is changes frequently i.e while recording it has name “Window1” and then while running its “Windows2” in this case how does QTP handles?
A)QTP handles those situations using “Regular Expressions”.

13) What is Parameterizing Tests?
A) When you test your application, you may want to check how it performs the same operations with multiple sets of data. For example, suppose you want to check how your application responds to ten separate sets of data. You could record ten separate tests, each with its own set of data. Alternatively, you can create a parameterized test that runs ten times: each time the test runs, it uses a different set of data.

14) What is test object model in QTP ?
A) The test object model is a large set of object types or classes that QuickTestuses to represent the objects in your application. Each test object class has alist of properties that can uniquely identify objects of that class and a set ofrelevant methods that QuickTest can record for it.A test object is an object that QuickTest creates in the test or component torepresent the actual object in your application. QuickTest stores informationabout the object that will help it identify and check the object during therun session.A run-time object is the actual object in your Web site or application onwhich methods are performed during the run session.

15) What is Object Spy in QTP?
A)Using the Object Spy, you can view the properties of any object in an openapplication. You use the Object Spy pointer to point to an object. The ObjectSpy displays the selected object’s hierarchy tree and its properties and valuesin the Properties tab of the Object Spy dialog box.

16) What is the Diff between Image check-point and Bit map Check point?
A) Image checkpoints enable you to check the properties of a Web image.You can check an area of a Web page or application as a bitmap. Whilecreating a test or component, you specify the area you want to check byselecting an object. You can check an entire object or any area within anobject. QuickTest captures the specified object as a bitmap, and inserts acheckpoint in the test or component. You can also choose to save only theselected area of the object with your test or component in order to save disk SpaceFor example, suppose you have a Web site that can display a map of a citythe user specifies. The map has control keys for zooming. You can record thenew map that is displayed after one click on the control key that zooms inthe map. Using the bitmap checkpoint, you can check that the map zoomsin correctly.You can create bitmap checkpoints for all supported testing environments(as long as the appropriate add-ins are loaded).Note: The results of bitmap checkpoints may be affected by factors such asoperating system, screen resolution, and color settings.

17) How many ways we can parameterize data in QTP ?
A) There are four types of parameters:
Test, action or component parameters enable you to use values passedfrom your test or component, or values from other actions in your test.

Data Table parameters enable you to create a data-driven test (or action)that runs several times using the data you supply. In each repetition, oriteration, QuickTest uses a different value from the Data Table.

Environment variable parameters enable you to use variable values fromother sources during the run session. These may be values you supply, orvalues that QuickTest generates for you based on conditions and optionsyou choose.

Random number parameters enable you to insert random numbers asvalues in your test or component. For example, to check how yourapplication handles small and large ticket orders, you can have QuickTestgenerate a random number and insert it in a number of tickets edit field.

18.If i give some thousand tests to execute in 2 days what do u do?
A.) Adhoc testing is done. It Covers the least basic functionalities to verify that the system is working fine.

19. How to Import data from a ".xls" file to Data table during Runtime.
A.) Datatable.Import "...XLS file name...
"DataTable.ImportSheet(FileName, SheetSource, SheetDest)
DataTable.ImportSheet "C:\name.xls" ,1 ,"name"

20.How to export data present in Datatable to an ".xls" file?
A.) DataTable.Export "....xls file name..."

21. 3 differences between QTP & Winrunner?
A.) (a) QTP is object bases Scripting ( VBS) where Winrunner is TSL (C based) Scripting.
(b) QTP supports ".NET" application Automation not available in Winrunner.
(c) QTP has "Active Screen" support which captures the application, not available in WR.
(d) QTP has "Data Table" to store script values , variables which WR does not have.
(e) Using a “point and click” capability you can easily interface with objects, theirdefinitions and create checkpoints after having recorded a script – without havingto navigate back to that location in your application like you have to with WinRunner.
This greatly speeds up script development.

22. how to add a runtime parameter to a datasheet?
Ans:DataTable.LocalSheet
The following example uses the LocalSheet property to return the local sheet ofthe run-time Data Table in order to add a parameter (column) to it.
MyParam=DataTable.LocalSheet.AddParameter("Time", "5:45")

23 .Object Repositories types, Which & when to use?
Deciding Which Object Repository Mode to ChooseTo choose the default object repository mode and the appropriate object repository mode for each test, you need to understand the differences between the two modes.
In general, the object repository per-action mode is easiest to use when you are creating simple record and run tests, especially under the following conditions:
You have only one, or very few, tests that correspond to a given application, interface, or set of objects.You do not expect to frequently modify test object properties.You generally create single-action tests.Conversely, the shared object repository mode is generally the preferred mode when:
You have several tests that test elements of the same application, interface, or set of objects.
You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties.
You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options.

24.How to execute a WinRunner Script in QTP?
A.) (a) TSLTest.RunTest TestPath, TestSet [, Parameters ] --> Used in QTP , used for backward compatibility
Parameters : The test set within Quality Center, in which test runs are stored. Note that this argument is relevant only when working with a test in a Quality Center project. When the test is not saved in Quality Center, this parameter is ignored.
e.g : TSLTest.RunTest "D:\test1", ""

(b)TSLTest.RunTestEx TestPath, RunMinimized, CloseApp [, Parameters ]
TSLTest.RunTestEx "C:\WinRunner\Tests\basic_flight", TRUE, FALSE, "MyValue"

CloseApp : Indicates whether to close the WinRunner application when the WinRunner test run ends.
Parameters : Up to 15 WinRunner function argument

25. How to handle Run-time errors?
(a) On Error Resume Next : causes execution to continue with the statement immediately following the statement that caused the run-time error, or with the statement immediately following the most recent call out of the procedure containing the On Error Resume Next statement. This allows execution to continue despite a run-time error. You can then build the error-handling routine inline within the procedure.
Using "Err" object msgbox "Error no: " & " " & Err.Number & " " & Err.description & " " & Err.Source & Err.HelpContext

26.How to change the run-time value of a property for an object?
A.) SetTOProperty changes the property values used to identify an object during the test run.Only properties that are included in the test object description can be set

27. How to retrieve the property of an object?
A.) using "GetRoProperty".

28. How to open any application during Scripting?
A.) SystemUtil , object used to open and close applications and processes during a run session.
(a) A SystemUtil.Run statement is automatically added to your test when you run an application from the Start menu or the Run dialog box while recording a test
E.g : SystemUtil.Run "Notepad.exe"SystemUtil.CloseDescendentProcesses ( Closes all the processes opened by QTP )

29. Types of properties that Quick Test learns while recording?
A.)(a) Mandatory (b) Assistive .
In addition to recording the mandatory and assistive properties specified in the Object Identification dialog box, QuickTest can also record a backup ordinal identifier for each test object. The ordinal identifier assigns the object a numerical value that indicates its order relative to other objects with an otherwise identical description (objects that have the same values for all properties specified in the mandatory and assistive property lists). This ordered value enables QuickTest to create a unique description when the mandatory and assistive properties are not sufficient to do so.

30. What is the extension of script and object repository files?
A.) Object Repository : .tsr , Script : .mts, Excel : Default.xls

31. How to supress warnings from the "Test results page"?
A.) From the Test results Viewer "Tools > Filters > Warnings"...must be "Unchecked".

32. How to covert a String to an integer?
A.) CInt()---> a conversion function available.

33.Which keyword used for Normal Recording?
A.) F3

34.Which keyword used for run the test script?
A.) F5

35.Which keyword used for stop the recording?
A.) F4

What is Difference between Winrunner and QTP

In QTP it supports dynamic pages where as in winrunner supports static pages only
In QTP we have more check points when compare to winrunner ( eg: XML,Text area check points etc )
In QTP we have one more option for recording where as in winrunner having two only (ie : Low Level recording in QTP)
we can call Functions of winrunner in QTP where as in winrunner there is no option for that
But the main functional difference is WinRunner doesnt support VB .Net,ASP .Net,C# .Net,SAP etc. But QTP supports all.
we can divide the script into actions i.e into logical units in QTP but we cannot split the script in winrunner, we can invoke Winrunner fron DOS promt and schedule but we dont have such option in qtp
winrunner is based on c but QTP is based on vb.
1.WinRunner supports HTML pages only. QTP supports both HTML&XML pages. 2.WinRunner supports static images. QTP supports dynamic images also3. WinRunner supports custom &run time.  QTP does not support custom check record checkrun time record check.
qtp: In this three types recording is possiblethey are 1)GENERAL RECORDING 2)ANALOG RECORDING 3)LOW LEVEL RECORDINGWINRUNNER: In this two types of recoring is possiblethey are 1)CONTEXT SENSITIVE RECORDING 2)ANALOG RECORDING
QTP supports different technologies like SAP applications, Macromedia applications, PeopleSoft etc which is not supported by WinRunner.
-------------------
QTP allows even novice testers to be productive in minutes. You can create a test script by simply pressing a Record button and using an application to perform a typical business process. Each step in the business process is automated documented with a plain-English sentence and screen shot. Users can easily modify, remove, or rearrange test steps in the Keyword View. 2.QTP can automatically introduce checkpoints to verify application properties and functionality, for example to validate output or check link validity. For each step in the Keyword View, there is an ActiveScreen showing exactly how the application under test looked at that step. You can also add several types of checkpoints for any object to verify that components behave as expected, simply by clicking on that object in the ActiveScreen. 3.You can then enter test data into the Data Table, an integrated spreadsheet with the full functionality of Excel, to manipulate data sets and create multiple test iterations, without programming, to expand test case coverage. Data can be typed in or imported from databases, spreadsheets, or text files. 4.Advanced testers can view and edit their test scripts in the Expert View, which reveals the underlying industry-standard VBScript that QuickTest Professional automatically generates. Any changes made in the Expert View are automatically synchronized with the Keyword View. 5.Once a tester has run a script, a TestFusion report displays all aspects of the test run: a high-level results overview, an expandable Tree View of the test script specifying exactly where application failures occurred, the test data used, application screen shots for every step that highlight any discrepancies, and detailed explanations of each checkpoint pass and failure. By combining TestFusion reports with Mercury Quality Management, you can share reports across an entire QA and development team. 6.QTP also facilitates the update process. As an application under test changes, such as when a ?Login? button is renamed ?Sign In,? you can make one update to the Shared Object Repository, and the update will propagate to all scripts that reference this object. You can publish test scripts to Mercury Quality Management, enabling other QA team members to reuse your test scripts, eliminating duplicative work. 7.QuickTest Professional supports functional testing of all popular environments, including Windows, Web, .Net, Visual Basic, ActiveX, Java, SAP, Siebel, Oracle, PeopleSoft, terminal emulators, and Web services.
In winrunner 2 types of TSL test script ie.
1.Main test
2.Compiled module
But in QTP,
only one type of test script ie.Main test.It doesn't support compiled module.
Main difference between winrunner & QTP is QTP Supports .netApplications & Full fledge java
Applications, these are not suppoerted by winrunner .
QTP having 9 check points where winrunner is having 4 check points.
we can create reuasble action in QTP but not in winner.
these are the major differences.