QTP Book

………. RK

QTP Content
Module-I (QTP Fundamentals & Features)
(1) Introduction & QTP Test Process
(2) Generating Tests
(3) Enhancing Tests
(4) Debugging & Running Tests
(5) QTP other features
Module-II (VB Script for QTP)
(6) VB Script Fundamentals & Features
(7) Data Types, Variables and Constants
(8) Operators
(9) Flow control (Conditional Statements)
(10) Flow control (Looping through the code)
(11) VB Script Built-in Procedures (Functions)
(12) VB Script User defined Procedures (Functions)
(13) VB Script other features
Module-III (QTP Scripting)
(14) File system operations (Scripts)
(15) Excel file operations (Scripts)
(16) Database operations (Scripts)
(17) GUI Scripting (Object state validations)
(18) GUI Scripting (Input Domain Validations)
(19) GUI Scripting (Output Domain Validations)
(20) Web Scripts (Crating web scripts)
(21) Web Scripts (Input Domain Validations)
(22) Web Scripts (Output Domain Validations)
Module-IV (QTP Framework)
(23) Overview on Automation Framework Design & Implementation
(24) Automation Resources development
(25) Implementing Basic Framework
(26) Implementing Data Driven Framework
(27) Implementing Keyword Driven Framework
**************************************************

Make your QTP scripts perform better

http://www.learnqtp.com/make-your-qtp-scripts-perform-better/

In this query jp@QTP is looking for ways to optimize QTP scripts for best performance. Everyone knows we use automated testing tools to optimize our testing process. Unless you make full use of the capability of the tool and unless a tool is used sensibly and with proper planning, it would not yield any results. Just record-and-playback is never the solution for any project. You need to go deep inside to understand the intricacies of any tool. Any software testing tool is only as good as the test engineer using it. On those thoughts, I feel this was one of the best questions asked in the forums of late.
Well, here are some of my tips and tricks to optimize the QTP scripts:

Launch QTP using a .vbs file and not the QTP desktop icon. You will notice a substantial increase in speed. [Refer the earlier post on How to open QTP using vbs file? ,you just need the 1st point of that post]
For large tests, always define variables, function in an external .vbs file and not inside a reusable action. Attach these files with your test scripts. If you define a variable or a function in an action, on every iteration of your test run, memory(RAM) will be allocated to those variables/functions and would not be released. Now as your script starts consuming more and more RAM, your System Under Test (SUT) will tend to become slower.
While running, QTP consumes a lot of memory by itself. It is always advisable to have lots of available RAM( much more than what is recommended by HP) and good processor speed on a system where you intend to install QTP. When you have tests (and hence QTP) running for a prolonged period if time, there are chances of memory leaks. To avoid memory leakage always restart QTP at some intervals of time. Using AOM you can automate this process. [If you want to go into details of effect of RAM on speed of computer read the post on RAM, Memory Usage thoroughly]
Avoid using hard coded wait(x) statement. Wait statement waits for full x seconds, even if the event has already occurred. Instead use .sync or exist statement. While using exist statement always have a value inside it.

For ex: .Exist(10) Here QTP will wait max till 10 seconds and if it finds the object at (say) 3 secs , it will resume the execution immediately thereby saving your precious time. On the other hand if you leave the parenthesis blank, QTP would wait for object synchronization timeout you have mentioned under File > Test Settings > Run Tab.

Make full use of what HP-QTP has provided you in the tool IDE. Use “Automatically Generate “With” statements after recording” option present under Tools > Options > General Tab. This will not only make your code look neater but also make your scripts perform better.
Make your own judgement whether you want to go for Descriptive Programming or Object Repository or mixed approach. Each approach has it own pros and cons that in turn is related to QTP performance.
Unless absolutely required, uncheck the options “Save still image capture to results” and “Save movie to results” present under Tools > Options > Run tab. These options definitely have some bearing on QTP run time performance.
Make the Run Mode as “fast”. This setting is present under Tool > Options > Run tab. Note: If you intend to run your scripts from QC no need to worry about this option, as the scripts WILL run in fast mode whether you want or not.
If you are new to automation or QTP. Read this beginner article on Automation Object Model (AOM). AOM simplifies many aspects of QTP scripting. It can help you in controlling QTP from an external file.
Make use of relative paths while calling reusable actions in your script. Using relative path would make your script portable and easy to manage. I will cover in detail how to’s and why’s of using relative paths in my next post.

Are you sure you want to use QTP?

More often than not, I have seen people going for test automation just because they want to go for this exciting buzzword. It is generally realized in the very end that automation has not given intended returns.I would suggest that before even thinking of Automation a thorough study of your application/system/module should be performed.

The following types of test cases are preferred (but not limited to) choice for automation:

Tests that need to run for every build.
Tests that use multiple data values for same action.
Identical tests that need to be executed using different browsers

The following types are not considered to be the good candidates for automation:

Test Cases that will only be executed once.
Test Cases used for Ad-hoc/random Testing.
Test Cases that are infrequently selected for execution.
Test Cases that will require manual intervention ie a task not possible to automate.
The most imp. one--based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.

Above all the effort required to develop and maintain the automated scripts should be weighed against the resources (no of hours, budget) that task would take while manual execution. The amount of changes the application undergoes from one build to another should also be taken into account while choosing for test automation.

If an app undergoes drastic changes that means most time will be exhausted in maintaining the scripts. These apps are then considered bad choice for automation.
Considering the above points Return On Investment (ROI) should be calculated and this should be the single most important criterion while going for Test Automation.

Some Useful Tips with QTP

Sharing some of the useful tips on QTP I used while working and found from sqaforums.I urge the readers to share their experiences/tips they have used while working on QTP. You can use the comments section to do the same.

1) How to add a constant number in a datatable?
This is more to do with MS excel then QTP!! but useful to know because at times it becomes frustrating to the novices.
Just append ' to the number
Ex: if you wish to enter 1234567 in datatable then write it as '1234567

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

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

4) My test fails due to checkpoint failing, Can i validate a checkpoint without my test failing due to checpoint failure?
Reporter.Filter = rfDisableAll 'Disables all the reporting stuff
chk_PassFail = Browser(...).Page(...).WebEdit(...).Check (Checkpoint("Check1"))
Reporter.Filter = rfEnableAll 'Enable all the reporting stuff
if chk_PassFail then
MsgBox "Check Point passed"
else
MsgBox "Check Point failed"
end if

5) What is the difference between an Action and a function?
Action is a thing specific to QTP while functions are a generic thing which is a feature of VB Scripting. Action can have a object repository associated with it while a function can't. A function is just lines of code with some/none parameters and a single return value while an action can have more than one output parameters.

6) Where to use function or action?
Well answer depends on the scenario. If you want to use the OR feature then you have to go for Action only. If the functionality is not about any automation script i.e. a function like getting a string between to specific characters, now this is something not specific to QTP and can be done on pure VB Script, so this should be done in a function and not an action. Code specific to QTP can also be put into an function using DP. Decision of using function/action depends on what any one would be comfortable using in a given situation.

7) When to use a Recovery Scenario and when to us on error resume next?
Recovery scenarios are used when you cannot predict at what step the error can occur or when you know that error won't occur in your QTP script but could occur in the world outside QTP, again the example would be "out of paper", as this error is caused by printer device driver. "On error resume next" should be used when you know if an error is expected and dont want to raise it, you may want to have different actions depending upon the error that occurred. Use err.number & err.description to get more details about the error.

8) How to use environment variable?
A simple defintion could be... it is a variable which can be used across the reusable actions and is not limited to one reusable action.
There are two types of environment variables:
1. User-defined
2. Built-in
We can retrieve the value of any environment variable. But we can set the value of only user-defined environment variables.

To set the value of a user-defined environment variable:
Environment (VariableName) = NewValue

To retrieve the value of a loaded environment variable:
CurrValue = Environment (VariableName)

Example
The following example creates a new internal user-defined variable named MyVariable with a value of 10, and then retrieves the variable value and stores it in the MyValue variable.

Environment.Value("MyVariable")=10
MyValue=Environment.Value("MyVariable")

9) What are the files and subfolders of a QuickTest Professional test?

The files and folders hold binary and text data that are required for the test to run successfully.
The following table provides a description, the type, and comments regarding the files that make up a QuickTest Professional test.

File Name	Description	Type	Comments Regarding File
Test.tsp	Test settings	Binary	Do not edit
Default.xls	Data table parameters	Excel similar	Can be edited using Excel
Parameters.mtr	Parameterization information	Binary	Do not edit
Action	Action folder (See other table)
Default.cfg	Load test configuration file	Text	Do not edit
Default.prm	Load test configuration file	Text	Do not edit
Default.usp	Load test configuration file	Text	Do not edit
.usr	Load test configuration file	Text	Do not edit
Thick_usr.dat	Load test configuration file	Text	Do not edit
Thin_usr.dat	Load test configuration file	Text	Do not edit

Files within Action folder:

File Name	Description	Type	Comments Regarding File
Script.mts	Action script	Text	Edit text preceding the @@ sign only
Resource.mtr	Object Repository	Binary	Do not edit
Snapshots	Active screen files	Folder	Do not edit

There are few more files extensions like

.MTB Batch File

.LCK Locked

10) How to rename a checkpoint (QTP 9.0)?
Example:
Window("Notepad").WinEditor("Edit").Check CheckPoint("Edit")
In the above example, the user would like to change the name of the CheckPoint object from "Edit" to something more meaningful.
Note:
This functionality is new to QuickTest Professional 9.0.This is not available for QTP 8.2 and below.
1. Right-click on the Checkpoint step in the Keyword View or on the Checkpoint object in Expert View.
2. Select "Checkpoint Properties" from the pop-up menu.
3. In the Name field, enter the new checkpoint name.
4. Click . The name of the checkpoint object will be updated within the script.
Example:
Window("Notepad").WinEditor("Edit").Check CheckPoint("NewCheckPointName")
Note:
You must use the QuickTest Professional user interface to change the name of the checkpoint. If you manually change the name of the checkpoint in the script, QuickTest Professional will generate an error during replay. The error message will be similar to the following:

"The "" CheckPoint object was not found in the Object Repository. Check the Object Repository to confirm that the object exists or to find the correct name for the object."

The CheckPoint object is not a visible object within the object repository, so if you manually modify the name, you may need to recreate the checkpoint to resolve the error.

11) Does QuickTest Professional support Internet Explorer 7.0?

QuickTest Professional 9.1
QuickTest Professional 9.1 supports Microsoft Internet Explorer 7.0 Beta 3. Internet Explorer version 7.0 is now certified to work and to be tested with QuickTest Professional version 9.1.
QuickTest Professional 9.0
QuickTest Professional 9.0 supports Internet Explorer 7.0 Beta 2.
QuickTest Professional 8.2 and below
QuickTest Professional 8.2 and below do not include support for Internet Explorer 7.0.

Does QuickTest Professional support Firefox?

QuickTest Professional 9.1 and 9.2
QuickTest Professional 9.1 provides replay support for Mozilla Firefox 1.5 and Mozilla Firefox 2.0 Alpha 3 (Alpha-level support for Bon Echo 2.0a3).
Notes:

QuickTest Professional 9.1 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.

The .Object property for web objects is not supported in FireFox.

QuickTest Professional 9.0

QuickTest Professional 9.0 provides replay support for Mozilla FireFox 1.5.
Notes:

QuickTest Professional 9.0 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.

The .Object property for web objects is not supported in FireFox.

QuickTest Professional 8.2 and below

QuickTest Professional 8.2 and below do not have support for Firefox.

12) Problem
After Quick Test Professional is started, Windows Media will not start. It returns the error message "wmplayer.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created."

If you start Window's Media Player first, it will continue to work normally after starting QuickTest Professional.

Solution:

Include the Windows Media Player's executable in the NoBBTApps section of the mic.ini file

1. Close QuickTest Professional.
2. Go to \bin\mic.ini.
3. Include wmplayer.exe in the NoBBTApps section of mic.ini file.

Example:
[NoBBTApps]
wmplayer.exe=rek

4. Save the mic.ini file and restart QuickTest Professional.

13) What is the lservrc file in QTP?

The lservrc file contains the license codes that have been installed

The lservrc file contains the license codes that have been installed. Whenever a new license is created, the license code is automatically added to this file. The lservrc file is a text file, with no extension.

File Location:

1) For a Concurrent (Floating) license installation:

C:\Program Files\Common Files\SafeNet\ SafeNet Sentinel\ LM Server\WinN

2) For a Seat (Stand-alone) license installation:

QTP 9.2 and below versions: C:\Program Files\Common Files\Mercury Interactive\License Manager\lservrc
QTP 9.5 and above versions: C:\Documents and Settings\All Users\Application Data\HP\Functional testing\License

14) What to do if you are not able to run QTP from quality center?
This is for especially for newbies with QTP.
Check that you have selected Allow other mercury products to run tests and components from Tools--> Options--> Run Tab. Check out QTP and QC guide.

15) Does QuickTest Professional support Macintosh operating systems?
No, QTP is not expected to run on this OS.

Note: Please use the Testing Tools forum for posting questions now!

Installing QTP’s trial version

I get at least 10 emails every week with the same question – “What license keys do I need to install the trial version?” I thought instead of writing an individual response each time, I will write a blog post on it so as to settle this once and for all.
Watch this short video on how to activate trial version of QuickTest Pro. Please remember that you don’t need any license keys to activate your trial.
In this video we assume that you have already downloaded QTP, started installation and you’re on the penultimate screen of QTP’s installation process.

QTP Testing Process

Test - A compilation of steps organized into one or more actions, which we can use to verify that our application performs as expected. A test is composed of actions (3 kinds of actions are there in QTP Non-reusable action, Reusable action and External action).

1) First step is Planning Before starting to build a test, you should plan it and prepare the required infrastructure. For example, determine the functionality you want to test, short tests that check specific functions of the application or complete site.Decide how you want to organize your object repositories.

2)Second step in QTP is Creating Tests or Components

We can create a test or component by

a) Either recording a session on your application or Web site.

As we navigate through the application or site, QuickTest graphically displays each step we perform as a row in the Keyword View. The Documentation column of the Keyword View also displays a description of each step in easy-to-understand sentences. A step is something that causes or makes a change in your site or application, such as clicking a link or image, or submitting a data form.

OR b) Build an object repository and use these objects to add steps manually in the Keyword View or Expert View. We can then modify your test or component with special testing options and/or with programming statements.

3)Third step is Inserting checkpoints into your test or component. A checkpoint is a verification point that compares a recent value for a specified property with the expected value for that property. This enables you to identify whether the Web site or application is functioning correctly.

4)Fourth step is

Broaden the scope of your test or component by replacing fixed values with parameters.

To check how your application performs the same operations with different data you can parameterize your test or component.

When you parameterize your test or component, QuickTest substitutes the fixed values in your test or component with parameters

Each run session that uses a different set of parameterized data is called an iteration.

We can also use output values to extract data from our test or component. An output value is a value retrieved during the run session and entered into the Data Table or saved as a variable or a parameter. We can subsequently use this output value as input data in your test or component.

We can use many functional testing features of QuickTest to improve your test or component and/or add programming statements to achieve more complex testing goals.

5)Fifth step is running the test

After creating test or component, we run it.

Run test or component to check the site or application.

When we run the test or component, QuickTest connects to your Web site or application and performs each operation in a test or component, checking any text strings, objects, or tables you specified. If we parameterized the test with Data Table parameters, QuickTest repeats the test (or specific actions in your test) for each set of data values we defined.

Run the test or component to debug it.

We can control the run session to identify and eliminate defects in the test or component. We can use the

Step Into,

Step Over,

And Step Outcommands to run a test or component step by step. We can also set breakpoints to pause the test or component at pre-determined points. We can view the value of variables in the test or component each time it stops at a breakpoint in the Debug Viewer.

6)Sixth step is analyzing the results

After we run test or component, we can view the results.

? View the results in the Results window.

After running the test or component, we can view the results of the run in the Test Results window. We can view a summary of the results as well as a detailed report.

? Report defects identified during a run session.

If Quality Center is installed, we can report the defects fond out to a database. We can instruct QuickTest to automatically report each failed step in the test or component, or we can report them manually from the Test Results window.

Explain Test object Model, test object and run-time object ?

Test object Model is a set of object types or Classes that QuickTest uses to represents the objects in our application.

A test object class comprises of a list of properties that can individually (uniquely) identify objects of that class and a set of appropriate methods that QuickTest can record for it.

A test object is an object that QuickTest creates in the test to correspond to (represent) the actual object in the application. QuickTest uses the stored information about the object during the run session to identify and check the object.

A run-time object is the real (actual) object in the application or Web site on which methods are performed during the run session.

Properties and methods of objects:

The property set for each test object is created and maintained by QuickTest. The property set for each run-time object is created and maintained by the object architect (creator) (Microsoft for Internet Explorer objects, Netscape for Netscape objects).

Similarly, methods of test objects are methods that QuickTest recognizes and records when they are executed (performed) on an object while we are recording, and that QuickTest executes when the test or component runs. Methods of Run-time object are the methods of the object in the application as defined by the object architect (creator). We can access and execute run-time object methods using the Object property.

Some important points to remember about methods and properties :

Each test object method we execute (perform) while recording is recorded as a separate step in the test. When we run the test, QuickTest executes (performs) the recorded test object method on the run-time object.
Properties of test object are captured from object while recording. QuickTest uses the values of these properties to identify runtime objects in the application during a run session.
Property values of objects in the application may change .To make the test object property values match the property values of the run-time object, we can modify test object properties manually while designing the test or component or using SetTOProperty statements during a run session. We can also use regular expressions to identify property values.
We can view or modify the test object property values that are stored with the test or component in the Object Properties or Object Repository dialog box.
We can view the syntax of the test object methods as well as the run-time methods of any object on our desktop using the Methods tab of the Object Spy.
We can retrieve or modify property values of the TEST OBJECT during the run session by adding GetTOProperty and SetTOProperty statements in the Keyword View or Expert View. We can retrieve property values of the RUNTIME OBJECT during the run session by adding GetROProperty statements.

If the available test object methods or properties for an object are not sufficient or they do not provide the functionality we need, we can access the internal methods and properties of any run-time object using the Object property. We can also use the attribute object property to identify Web objects in the application according to user-defined properties.

Object Repositories in QTP 9 (QuickTest Professional)

An object as we know is a graphic user element in an application e.g. a button or a list or an edit box and the special characteristics of an object within the QuickTest are called

object properties. QTP stores the recorded object properties in Object Repository.

Object Repositoriesare of two types Local and shared.

If objects are stored in a Local Object Repository then these are available to specific actions but not to all the actions. But if these objects are stored in one or more Shared Object Repositories then multiple actions or tests can use them.

By default QTP makes and uses Local Object Repository. If we create a new blank test and do a recording on it, QTP automatically creates a Local Object Repository for that test or action and stores the information about any object it finds in that corresponding Object Repository.

In QTP 9 we can associate multiple Shared Object Repositories with an action. If multiple Shared Object Repositories are associated with an action then also while recording QTP stores objects in corresponding Local Object Repository on the condition that those objects are not already stored in any corresponding associated Shared Object Repositories. This is the default that every time we create a new action QTP creates a new corresponding Local Object Repository. It is also true that Object Repositories are associated with actions and no matter how many times we learn or record on the same object in our application in different actions the object will be stored as separate test object in each of the Local Object Repository. Local Object Repository is automatically saved with the test when we save it. The extension of the Local Object Repository is .mtr, but it is not accessible as a separate file as in case of the Shared Object Repository.

We can also manipulate some aspects of Local Object Repository using Quick test Object Repository Automation Object Model. For example we can add, remove, rename test objects in Local Object Repository. (QuickTest Object Repository Automation documents the Object Repository automation object model that enables you to manipulate QuickTest object repositories and their contents from outside of QuickTest.)

When we open a test that was created using a version of QTP earlier that version 9 we are asked whether we want to convert it or view it in read only format. In any case if the test previously used per-action Object Repository, the objects in each per action repository are moved to the Local Object Repository of each action in the test.

If the test previously used a shared object repository, the same shared object repository is associated with each of the actions in the test, and the local object repository is empty.

While learning or recording we can specify Shared Object Repository for the selected action. We can specify and associate one or more Shared Object Repositories with each action. We can also create new Shared Object Repository and associate it with our action.

In case of Shared Object Repository, QTP uses existing information and does not add objects to the Object Repository if we record operations on an object that already exists either in Shared or Local Object Repository.

As said earlier QTP does not add objects directly to the associated Shared Object Repository as we record, instead it adds new objects in Local Object Repository (if that object does not already exist in associated Shared Object Repository).

We can surely export Local objects to Shared Object Repository.

There are different ways in which we can move objects from Local Object Repository to Shared Object Repository:

1) Exporting the objects to the Shared Object Repository from the Local Object Repository: In Object Repository window choose the action whose local objects you want to move. Choose File-> Export Local Objects.Select the location in which you want to save the file. Click on save.

2) We can update the Shared Object Repository with the Local Object Repository:

f we create a new test it will be created with Local Object Repository, we can associate any new or old Shared Object Repository with it, and so we can update that Shared Object Repository with Local Object Repository.

In Object Repository Manager open the Shared Object Repository (clear open in read only check box).

The test in this case should not be open. In Object Repository Manager go to Tools –> Update From Local Repository. Select the test who's Local Object Repository you want to use. Click update all. It will move all the objects to the Shared Object Repository.

3) We can also merge objects from two Object Repositories (called as primary and secondary in QTP 9) into a new single Object Repository (target Object Repository in QTP 9). The original source files are not changed. It also enables you to merge objects from Local Object Repository of one or more action(s) into a Shared Object Repository. It is recommended to use as a primary Object Repository the file in which you have invested alot of your effort, like which has more number of objects.

We can compare two Object Repositories using the Object Repository Comparison Tool. The tool enables you to identify similarities, variations or changes between two Object Repositories.

We can also copy objects to Local Object Repository from the Shared Object Repository. We can copy, paste and move objects in Local Object Repository and copy, paste and move objects within Shared Object Repository and between Shared Object Repositories.As said earlier we can also copy objects from shared Object Repository to Local Object Repository to modify them locally.

We cannot remove an association between the action and its Local Object Repository.

Checkpoints in QTP

A checkpoint enables you to identify whether the Web site or application under test is functioning correctly or not by comparing a current value for a particular property with the expected value for that property.

After we add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and adds a Check CheckPoint statement in the Expert View.

By default, the checkpoint name receives the name of the test object on which the checkpoint is being performed. We can change the name of the checkpoint if needed.

Types of Checkpoints:

Standard checkpoint.
Image checkpoints.
Bitmap Checkpoint.
Table checkpoints.
Accessibility Checkpoint.
Text Checkpoint.
Page Checkpoint.
Database Checkpoint.
XML checkpoints.

Standard checkpoints allow checking the object property values in the Web site or application under test. Standard checkpoints evaluate (compare) the expected values of object properties captured during recording to the object's current values during a run session. For example we can check that a radio button is activated after it is selected. Standard checkpoints are supported for all add-in environments.

Standard checkpoints can be used to perform checks on

Images,

Tables,

Web page properties, and

Other objects within your application or Web site.

Standard checkpoints can be created for all supported testing environments (as long as the appropriate add-in(s) are loaded).

Image checkpoints allow you to check the properties of an image in the application or Web page. For example, you can check that a selected image's source file is correct or not. An image checkpoint can also be created by inserting a standard checkpoint on an image object. Image checkpoints are supported for the Web add-in environment

With Bitmap Checkpoint we can check an area of a Web page or application as a bitmap. While creating a test, we have to specify the area to check by selecting an object. An entire object or any area within an object can be checked. Bitmap checkpoints are supported for all add-in environments

By adding table checkpoints to the test, we can check the content of tables displayed in the application. For example, we can check that a specified value is displayed in a certain cell. Certain environments also support checking the properties of the table object. For example, a check that a table has the expected number of rows and columns. A table checkpoint can also be created by inserting a standard checkpoint on a table object.

Accessibility Checkpoint recognizes areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, check if the images on a Web page include ALT properties, required by the W3C Web Content Accessibility Guidelines.

Accessibility checkpoints are supported for the Web add-in environment

QuickTest can check that a text string is displayed in the appropriate place in an application or on a Web page with Text Checkpoint. Text checkpoints are supported for the Web add-in environment, plus some Web-based add-in environments

Page Checkpoint checks the features of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links. A page checkpoint can also be created by inserting a standard checkpoint on page object. Page checkpoints are supported for the Web add-in environment

The contents of a database accessed by your application can be checked by Database Checkpoint. Database checkpoints are supported for all add-in environments

By adding XML checkpoints to your test, you can check the contents of individual XML data files or documents that are part of your Web application. The XML Checkpoint option is supported for all add-in environments.

QTP (QuickTest Professional) Recording

The default mode of recording is the Normal recording mode. There are other

recording modes also like

Analog Recording or Low Level Recording. Normal mode is the default and takes full advantage of the QuickTest test object model, as it recognizes the objects in the application regardless of their location on the screen. Analog Recording : Exact mouse and keyboard operations are recorded in relation to either the screen or the application window. In this QTP also records and tracks every movement of the mouse for example, recording a signature produced by dragging the mouse. Analog Recording steps are not editable from within QuickTest.

Low Level Recording : At any time, if an environment or on an object not recognized by QuickTest, use Low Level Recording. It records at object level and records all run-time objects as Window or WinObject test objects. QuickTest records all parent level objects as Window test objects and all other objects as WinObject test objects.

Each step recorded in Low Level Recording mode is shown in the Keyword View and Expert View. All the three modes of recording can be used in a single test e.g. we can switch to either Analog Recording or Low Level Recording in the middle of a recording session for specific steps and then return to normal recording mode.

Analog Recording and Low Level Recording require more disk space than normal recording mode.

Use Analog Recording when :

The actual movement of the mouse is what you want to record.

Recording in Analog mode can be relative to the screen or relative to a specific window

In Analog Recording a separate file is saved and stored with the action.

In Analog Recording mode, QuickTest adds to your test a RunAnalog statement that calls the recorded analog file.

Use Low Level Recording when :

Environments or objects not supported by QuickTest.

Exact location of the operation on your application screen is necessary. in normal mode QuickTest performs the step on an object even if it has moved to a new location on the screen.

If the location of the object is important to your test, switch to Low Level Recording.

Parameterizing Tests in QTP (QuickTest Professional)

By replacing fixed values with parameters QuickTest enables you to enlarge the scope of a basic test. It is known as

parameterization, greatly increases the power and flexibility of a test. A parameter is a variable that is assigned a value from an external data source or generator. Values in steps and checkpoints and also the values of action parameters can be parameterize. Parameters let us check how the application performs the same operations with multiple sets of data.

There are four types of parameters:

Test/action parameters: Test parameters make possible for us to use values passed from the test. Action parameters enable us to pass values from other actions in your test. To use a value within a specific action, the value must be passed down through the action hierarchy of the test to the required action. We can then use that parameter value to parameterize a step in the test. For example, suppose that we want to parameterize a step in Action3 using a value that is passed into the test from the external application that runs (calls) the test. We can pass the value from the test level to Action1 (atop-level action) to Action3 (a nested action of Action1), and then parameterize the required step using this action input parameter value (that was passed through from the external application). Alternatively, we can pass an output action parameter value from an action step to a later sibling action at the same hierarchical level. For example, suppose that Action2, Action3, and Action4 are sibling actions at the same hierarchical level, and that these are all nested actions of Action1. We can parameterize a call to Action4 based on an output value retrieved from Action2 or Action3. We can then use these parameters in the action step.

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

Environment variable parameters allow us to use variable values from other sources during the run session. These may be values that we supply, or values that QuickTest generates for us based on conditions and options we choose.

Random number parameters enable us to insert random numbers as values in your test.

Values in steps and checkpoints can be parameterized while recording or editing the test.

The values of object properties can be parameterized for a selected step.

The values of the operation (method or function arguments) defined for the step can also be parameterized.

When the value of an object property for a local object is parameterized, we are amending the test object description in the local object repository. Therefore, all occurrences of the specified object within the action are parameterized.

Parameterizing the value of a checkpoint property enables us to check how an application or Web site performs the same operation based on different data.

QTP (QuickTest Professional) keyword view

In QTP (QuickTest Professional) we first of all record a test, then run a test and then analyze the results, but before running the test we can also enhance it with checkpoints and parameters.

First of all let's talk a little about keyword view in QTP and then we will talk about recording in QTP and then we will move on to other things. After recording all the operations, QuickTest displays them as steps in the Keyword View, and generates them in a script (in an Expert View).

In the keyword view there are 4 visible columns –

Item- The item on which we want to perform the step and it can be a test object, utility object, function call, or statement. This column shows a hierarchical icon-based tree. The highest level of the tree is actions, and all steps are contained within the relevant branch of the tree.

Operation- The operation (methods or functions) to be performed on the item selected in the Item column, for example, Click or Select.

Value- The argument values for the selected operation, for example, the mouse button to use when clicking the image.

Documentation- It is a Read-only auto-documentation of what the step does in an easy-to-understand sentence, for example, Click the "findFlights" image.

Assignment- The assignment of a value to or from a variable for example, Store in cCols would store the return value of the current step in a variable called cCols so you can use the value later in the test. This column is not visible by default.

Comment- Any textual information you want to add regarding the step. This column is also not visible by default.

VBScript in QTP

Scripting language for Quick Test Professional (QTP) is VBScript.

VBScript (short for Visual Basic Scripting Edition) is a lively Scripting language interpreted via Microsoft's Windows Script Host.

VBScript has many powerful functions and provides excellent support for variables, data types, and error handling.

Two script engines can interpret VBScript- VBScript.dll, which is invoked by asp.dll is used in web environment and Wscript.exe & Cscript.exe in Windows GUI environment using Windows script Host (WSH, We typically use VBScript within WSH to automate systems administration tasks. WSH is the system module that transforms a VBScript file into a Windows executable file). Wscript.exe is used to display output and receive input in Windows GUI format such as dialog and input boxes. Cscript.exe is used in a command-line environment. When VBScript source code is contained in stand-alone files, they have the file extension .vbs

Actions in QTP 9 (QuickTest Professional)

Actions break up the test into logical sections/units such as specific activities that we perform in our application.

When we create a new test, it contains a call to one action. By breaking up the tests into calls to multiple actions, we can design more modular and well organized and professional tests. An action has its own test script, containing all of the steps recorded in that action, and all objects in its local object repository. An action is stored with the test in which you created it.

If you create a test in which you log into the system (email), check inbox, and then log out of the system (email), your test might be structured as shown—one test calling three separate actions:

Test 1		Actions stored with Test 1
Call to action 1	--->	Action 1(Logging In)
Call to action 2	--->	Action 2(Checking Inbox Mails)
Call to action 3	--->	Action 3(Logging Out)

Actions make it possible to parameterize and iterate over specific elements of a test. They also make it easier to re-record steps in one action when part of your application changes. For every action called in the test, QuickTest creates a corresponding action sheet in the Data Table so that we can enter Data Table parameters that are specific to that action only.

Three types of actions are: Non-reusable action This non reusable action can be called only once and that too in the test with which it is stored.

Reusable action Reusable actions are like functions in any programming language. If there is a process that needs to be included in several tests, we can record, modify, and enhance the steps of the process and save them in a reusable action. Then we can call the action from other tests, rather than recording, modifying, and enhancing the same steps each time. It can be called several times by the test with which it is stored (the local test), as well as by other tests.

Deleting a reusable action that is called by other tests will cause those tests to fail.

External action is a reusable action stored with another test. External actions are read-only in the calling test, but we can choose to use a local, editable copy of the Data Table information for the external action. When a call to an external action is inserted, the action is inserted in read-only format

We can create an additional call to any reusable or external action in the test by pressing CTRL while we drag and drop the action to another location at a parallel (sibling) level within the test.

By default, new actions are non-reusable. Each action created in a test can be marked as reusable or non-reusable.

When we run a test with multiple actions, the test results are divided by actions within each test iteration so that we can see the outcome of each action, and can view the detailed results for each action individually.

If you expect other users to open your tests and all actions in your tests are stored in the same drive, you should use relative paths for your reusable actions so that other users will be able to open your tests even if they have mapped their network drives differently.

QTP video tutorial - How to record QTP script

http://motevich.blogspot.com/

The present QTP (QuickTest Pro) video tutorial covers the following:

How to record QTP script for Web applications
What record and run settings should be used to run and execute QTP script
How to replay/execute QTP script
How to get results of executed QTP script
How to enable capturing screenshots during QTP scipt replaying
How to enable capturing video during QTP scipt replaying

http://www.guru99.com/quick-test-professional-qtp-tutorial.html

http://forums.sureshkumar.net/testing-tools-qa/22288-learn-qtp.html

http://qtp.blogspot.com/

http://www.onestopsoftwaretesting.com/qtp-overview-basics-of-qtp/

 VBScript
QTP uses VBScript language. That's why strong knowledge of VBScript is 'must have'.
Sources:

 Software Testing Automation Frameworks
To write good automated tests, you should know how to write them.
There are different approaches and solution. There is not a silver bullet.
Sources:

 HP Quick Test Professional Tutorial
This QTP tutorial came’s with QTP.
It's quite clean and informative. Its main goal is to show and explain basic concepts of Quick Test Professional. It provides knowledge on:

creating a test
working with Object Repository (OR)
running and analyzing tests
verifying tests
parameterizing, etc

Sources: '\help\QTTutorial.pdf' or '\help\Tutorial.chm' in QTP Install folder.

 HP Quick Test Professional User's Guide
As previous tutorial, the present User's Guide come with QTP install too.
This guide is intended for Quick Test Professional users at all levels. It gives a deeper knowledge on:

working with QTP Object Repositories
designing tests
enhancing tests (checkpoints, parameterizing, etc)
maintaining any debugging tests
advanced testing features, etc

Sources: '\help\QTUsersGuide.pdf' or '\help\MainUsersGuide.chm' in QTP Install folder.

 COM/DCOM Technologies
when working with QTP, you will be closely linked with such Microsoft's applications, as: Excel, Word, and Outlook. So, I recommend getting familiar with COM, COM Technologies, and COM objects of:

 SQL
SQL is so important in programming that I strongly recommend to spend time to learn SQL:

concepts of RDBM
selecting/updating/deleting data
SQL queries optimizations
databases administration

Sources:

 XML
XML is an extremely popular and useful format. I'm sure that you will have to deal with data, stored in XML-files.
Sources:

w3schools' XML tutorial

 HTML, DOM
Since Quick Test Professional works perfectly with web applications, you should be expert in related fields - HTML, HTTP, DHTML, DOM, etc. They will simplify your future QTP script and make them more reliable and maintainable.
Sources:

 HP QTP Knowledge Base
It contains a lot of practical articles about Quick Test Professional.
You can find there QTP webinars, QTP FAQs, documentations, solutions of your problems or different ways how to improve your QTP automated tests.
Sources:

HP Self-solve Knowledge Search (requires an access to HP site)

Useful sites
Sure, it's impossible to know all information on QTP.
That's why I recommend to use these two sites to search answers to your QTP questions:

Learning basics of QTP automation tool and preparation of QTP interview questions

This post is in continuation with QTP interview questions series. Following questions will help for preparing interview as well as learning the QTP basics.
Quick Test Professional: Interview Questions and answers.
1. What are the features and benefits of Quick Test Pro(QTP)?
1. Key word driven testing
2. Suitable for both client server and web based application
3. VB script as the script language
4. Better error handling mechanism
5. Excellent data driven testing features
2. How to handle the exceptions using recovery scenario manager in QTP?
You can instruct QTP to recover unexpected events or errors that occurred in your testing environment during test run. Recovery scenario manager provides a wizard that guides you through the defining recovery scenario. Recovery scenario has three steps
1. Triggered Events
2. Recovery steps
3. Post Recovery Test-Run
3. What is the use of Text output value in QTP?
Output values enable to view the values that the application talks during run time. When parameterized, the values change for each iteration. Thus by creating output values, we can capture the values that the application takes for each run and output them to the data table.
4. How to use the Object spy in QTP 8.0 versions?
There are two ways to Spy the objects in QTP
1) thru file toolbar: In the File Toolbar click on the last toolbar button (an icon showing a person with hat).
2) Thru Object repository Dialog: In Object repository dialog click on the button “object spy…” In the Object spy Dialog click on the button showing hand symbol. The pointer now changes in to a hand symbol and we have to point out the object to spy the state of the object. If at all the object is not visible or window is minimized then holds the Ctrl button and activate the required window to and releases the Ctrl button.
5. What is the file extension of the code file and object repository file in QTP?
File extension of
per test object rep: filename.mtr
Shared Object rep: filename.tsr
Code file extension id: script.mts
6. Explain the concept of object repository and how QTP recognizes objects?
Object Repository: displays a tree of all objects in the current component or in the current action or entire test ( depending on the object repository mode you selected).
We can view or modify the test object description of any test object in the repository or to add new objects to the repository.
Quick test learns the default property values and determines in which test object class it fits. If it is not enough it adds assistive properties, one by one to the description until it has compiled the unique description. If no assistive properties are available, then it adds a special Ordianl identifier such as objects location on the page or in the source code.
7. What are the properties you would use for identifying a browser and page when using descriptive programming?
“name” would be another property apart from “title” that we can use. OR
We can also use the property “micClass”.
ex: Browser(“micClass:=browser”).page(“micClass:=page”)
8. What are the different scripting languages you could use when working with QTP?
You can write scripts using following languages:
Visual Basic (VB), XML, JavaScript, Java, HTML
9. Tell some commonly used Excel VBA functions.
Common functions are:
Coloring the cell, Auto fit cell, setting navigation from link in one cell to other saving
10. Explain the keyword create object with an example.
Creates and returns a reference to an Automation object
syntax: Create Object (servername.typename [, location])
Arguments
servername:Required. The name of the application providing the object.
Type name: Required. The type or class of the object to create.
Location: Optional. The name of the network server where the object is to be created.
11. Explain in brief about the QTP Automation Object Model.
Essentially all configuration and run functionality provided via the QuickTest interface is in some way represented in the QuickTest automation object model via objects, methods, and properties. Although a one-on-one comparison cannot always be made, most dialog boxes in QuickTest have a corresponding automation object, most options in dialog boxes can be set and/or retrieved using the corresponding object property, and most menu commands and other operations have corresponding automation methods. You can use the objects, methods, and properties exposed by the QuickTest automation object model, along with standard programming elements such as loops and conditional statements to design your program.
12. How to handle dynamic objects in QTP?
QTP has a unique feature called Smart Object Identification/recognition. QTP generally identifies an object by matching its test object and run time object properties. QTP may fail to recognize the dynamic objects whose properties change during run time. Hence it has an option of enabling Smart Identification, wherein it can identify the objects even if their properties changes during run time.
Check out this:
If Quick Test is unable to find any object that matches the recorded object description, or if it finds more than one object that fits the description, then QuickTest ignores the recorded description, and uses the Smart Identification mechanism to try to identify the object.
While the Smart Identification mechanism is more complex, it is more flexible, and thus, if configured logically, a Smart Identification definition can probably help QuickTest identify an object, if it is present, even when the recorded description fails.
The Smart Identification mechanism uses two types of properties:
Base filter properties – The most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link’s tag was changed from to any other value, you could no longer call it the same object. Optional filter properties – Other properties that can help identify objects of a particular class as they are unlikely to change on a regular basis, but which can be ignored if they are no longer applicable.
13. What is a Run-Time Data Table? Where can I find and view this table?
In QTP, there is data table used, which is used at runtime.
-In QTP, select the option View->Data table.
-This is basically an excel file, which is stored in the folder of the test created, its name is Default.xls by default.
14. How does Parameterization and Data-Driving relate to each other in QTP?
To data driven we have to parameterize. i.e. we have to make the constant value as parameter, so that in each interaction(cycle) it takes a value that is supplied in run-time data table. Through parameterization only we can drive a transaction (action) with different sets of data. You know running the script with the same set of data several times is not suggested, and it’s also of no use.
15. What is the difference between Call to Action and Copy Action.?
Call to Action: The changes made in Call to Action, will be reflected in the original action (from where the script is called). But where as in Copy Action , the changes made in the script ,will not effect the original script(Action)
16. Explain the concept of how QTP identifies object.
During recording qtp looks at the object and stores it as test object. For each test object QT learns a set of default properties called mandatory properties, and look at the rest of the objects to check whether this properties are enough to uniquely identify the object. During test run, QTP searches for the run time objects that matches with the test object it learned while recording.
17. Differentiate the two Object Repository Types of QTP.
Object repository is used to store all the objects in the application being tested.
Types of object repository: Per action and shared repository.
In shared repository only one centralized repository for all the tests. where as in per action for each test a separate per action repository is created.
18. What the differences are and best practical application of Object Repository?
Per Action: For Each Action, one Object Repository is created.
Shared: One Object Repository is used by entire application
19. Explain what the difference between Shared Repository and Per Action Repository
Shared Repository: Entire application uses one Object Repository , that similar to Global GUI Map file in WinRunner
Per Action: For each Action, one Object Repository is created, like GUI map file per test in WinRunner
20. Have you ever written a compiled module? If yes tell me about some of the functions that you wrote.
Sample answer (You can tell about modules you worked on. If your answer is Yes then You should expect more questions and should be able to explain those modules in later questions): I Used the functions for Capturing the dynamic data during runtime. Function used for Capturing Desktop, browser and pages.
21. Can you do more than just capture and playback?
Sample answer (Say Yes only if you worked on): I have done Dynamically capturing the objects during runtime in which no recording, no playback and no use of repository is done AT ALL.
-It was done by the windows scripting using the DOM(Document Object Model) of the windows.
22. How to do the scripting. Are there any inbuilt functions in QTP? What is the difference between them? How to handle script issues?
Yes, there’s an in-built functionality called “Step Generator” in Insert->Step->Step Generator -F7, which will generate the scripts as you enter the appropriate steps.
23. What is the difference between check point and output value?
An output value is a value captured during the test run and entered in the run-time but to a specified location.
EX:-Location in Data Table[Global sheet / local sheet]
24. How many types of Actions are there in QTP?
There are three kinds of actions:
Non-reusable action – An action that can be called only in the test with which it is stored, and can be called only once.
Reusable action – An action that can be called multiple times by the test with which it is stored (the local test) as well as by other tests.
External action – A reusable action stored with another test. External actions are read-only in the calling test, but you can choose to use a local, editable copy of the Data Table information for the external action.
25. I want to open a Notepad window without recording a test and I do not want to use System utility Run command as well. How do I do this?
You can still make the notepad open without using the record or System utility script, just by mentioning the path of the notepad “( i.e. where the notepad.exe is stored in the system) in the “Windows Applications Tab” of the “Record and Run Settings window.

What is VBScript?

VBScript is a scripting language
A scripting language is a lightweight programming language
VBScript is a light version of Microsoft's programming language Visual Basic

How Does it Work?

When a VBScript is inserted into a HTML document, the Internet browser will read the HTML and interpret the VBScript. The VBScript can be executed immediately, or at a later event.
How to Put VBScript Code in an HTML Document

Overview
QTP is a UI automation framework designed mainly for Windows and Web-based applications. It works by identifying the objects in the application UI or a web page and performing the desired operations on them (like mouse clicks or keyboard events); it can also be used to capture object properties like name or handler ID etc. One of the most important topics in QTP is Object Identification.QTP uses a scripting language built on top of VBScript to specify the test procedure, and to manipulate the objects and controls of the application under test.
Though QTP is usually used for “UI Based” Test Case Automation, it can easily handle “Non-UI” based Test Cases. (e.g. API (Certification testing), Database Testing, etc.)
Some of the key features of QTP are:
Plug-ins
Plug-ins are used to make recording more acceptable to a specific application, we use web plug-ins to automate test cases with respect to web applications. QTP has default plug-ins for ActiveX controls, web applications and VB objects. Plug-ins for other objects, such as Microsoft .NETobjects, are also available. Multimedia plug-ins and a plug-in for Windows Mobile are also available. In general, each QTP plug-in is available at an additional cost.
And QTP identifies the windows objects, even if we don’t select any plug-ins at the launching of the application .
License Models
Three types of licenses are available from HP:
1. Demo License : a 14-day demo license
2. Seat license : permanent seat license that is specific to the computer on which it is installed.
3. Floating (Concurrent): Floating allows a license to be shared between machines at any given point in time. (1 floating license allows QTP to be accessible from an entire lab’s worth of PCs but can only have 1 instance running at any given point in time).
Record and Playback
Initial development of automated tests with QTP is usually done by record-and-playback. A user’s actions are captured via Microsoft’s Component Object Model (COM). These are recorded into Actions, a kind of subroutine, as VBScript commands. All manipulated objects that QTP recognizes are also added to the object repository. Once recorded, the scripts are editable in either Keyword View or Expert View.
After clicking on the playback button all these actions will be played back. During playback, QTP attempts to identify and perform operations on the same objects, again using COM.
Checkpoints
Checkpoints are a feature used for verifying the application under test. One can add a checkpoint to check if a particular object, text or a bitmap is present in the automation run.
In short, checkpoints are used to verify that during the course of test execution, the actual application behavior or state is consistent with the expected application behavior or state.
There are 10 types of checkpoints available in QTP:
1. Standard Checkpoint — Checks the properties of an object.
2. Table Checkpoint — A Standard Checkpoint that checks the properties of a table.
3. Image Checkpoint — A Standard Checkpoint that checks the properties of an image.
4. Bitmap Checkpoint — Compares an area of the application under test pixel-for-pixel with the screen as seen at record-time.
5. Database Checkpoint — Used to automate back-end testing.
6. Text Checkpoint — Checks that a section of text is found between two other sections of text.
7. Text Area Checkpoint
8. Page Checkpoint — Checks the properties of a web page.
9. Accessibility Checkpoint — Checks the accessibility of an application.
10. XML Checkpoint
The VBScript Reporter.ReportEvent function also produces output very similar to that of a checkpoint, allowing the creation of custom checkpoints.
Recovery
Recovery is the name for exception handling in QTP, with the goal of enabling the tests to continue to run if an unexpected failure occurs. For instance if an application crash occurs and a message dialog appears, QTP can be instructed to attempt to restart the application and continue with the rest of the test cases from there
Output Value
This feature is used to store the run-time values/data that are displayed in the application into the run-time data table, so that we can use these run-time values in the script for further use.
Say we need the value which is dynamically created or processed by application for later use, we can go for output concept. We can follow the following example to understand. If the application produces an id for the person and we need that id, that can be solved using output concept, where we store value ‘id’ of that person in the data table and we can refer to that value later.
Data Table
The data table is a table primarily used to implement data-driven testing. It is implemented as a Microsoft Excel workbook that can be accessed from within QTP. There are two types of Data Tables available in QTP: the Global data sheet and the local data sheets. The Global data sheet is a single sheet which is accessible from every Action in a test. By default, each row of this sheet specifies the values to be used in an iteration of the entire test. The data table can be managed by other third party tools such as Grid Tools Datamaker, which offers features such as Data inheritance; substitution variables and version control.
There is also one local data sheet associated with each Action. As the Global data sheet specifies iterations of an entire test, these sheets are often used to set up iterations of a single Action. The data in these sheets can only be accessed from their associated Action. While it is possible to access a different Action’s local data sheet, it cannot be done from the Object Repository or from inside a checkpoint.
Virtual Objects
Complex objects may not be recognized properly by QTP. The Virtual Object concept was implemented to enable users to add some degree of support for these objects. If an object is not recorded out-of-the-box, an experienced user may be able to define that object as a personal virtual object and build a virtual object repository. Assuming that the required information can be extracted from the object, this allows the users to successfully record and playback against that object. In practice, this is not always possible.
Transactions
This feature can be used to calculate the time required to run a particular test or particular steps in the tests. Transactions are most often used in automated software performance testing, so they are infrequently used in QTP(Quick test Professional)
Results
QTP generates the result file for the test cases at the end of test in the form of XML tree. The result file provides detail regarding PASS and FAILS counts, error messages, and potentially supporting information that allows users to determine the underlying cause of a failure.
User Interface
QuickTest provides two main views of a script: Keyword View and Expert View. They are selected from tabs at the bottom of the QuickTest Professional window.
Keyword View
Keyword View is QTP’s default test procedure interface. It displays the automation steps of a test procedure as a descriptive tree of Actions and functions. The tree contains columns listing the Action or function name, any parameters, and comments. This mode is most useful for the beginners in operating with the tool. This view allows the user to select the objects either from the application or from the Object Repository and the user can select the methods to be performed on those objects. The script is automatically generated. Users can also set check points from keyword view.
Expert View
In Expert View, QTP allows display and editing of the a test’s source code. All test actions can be edited here except for the root Global action. Expert View acts as an IDE for the test. It includes most standard IDE features, such as breakpoints. This view is most suitable for the advanced users, enabling them to customize the test, such as by writing user-defined functions.
Languages
Supports VB Script. Supports classes but not supports polymorphism and inheritance.

Details on QTP 11 Certification (HP0-M47)

With the introduction of QTP 11, it seems HP is keen to change many things. Earlier they used to come up with a new certification only after a gap of 2-3 years. QTP 11 was introduced in Sep’10 . In July 2011, HP has already announced the arrival of QTP 11 certification. QTP 10 certification thus becomes obsolete now. In case you are looking for QTP 11 certification read on…

What are the major changes between QTP 10.0 certification exam and QTP 11.0 certification exam?

In QTP 10.0 and earlier versions you need to take both QC exam(HP0-M31) AND QTP exam(HP0-M39) to get AIS certificate from HP. Starting with QTP 11/ALM 11, you just need to take one core exam that is HP AIS – Functional Testing v11 (Code HP0-M47) OR HP Application Lifecycle Management 11.x Software (Code HP0-M46).
Since you are reading a QTP blog, I assume you would want to take HP AIS – Functional Testing v11 (Code HP0-M47) exam. (Informally known as QTP 11 certification exam)

What to expect in HP0-M47: HP QuickTest Professional 11.0 exam?

Number of items: 72
Item types: multiple choice, drag-and-drop, and point and click
Exam time: 105 minutes
Passing score: 75%

[Source: HP QTP 11 exam preparation guide]

What is the syllabus for QTP 11 certification exam?

Please check the table below.

HP0-M47 Sections/Objectives
10%	Automated test planning • Plan for general testing and automation. • Plan for QTP testing. • Identify and describe features and settings. • Explain QTP licensing and packaging.
19%	Basic test creation and how QTP works with objects • Create the basic test. • Explain how QTP works with objects. • Add steps without recording. • Explain the purpose and operation of Smart Identification feature
24%	Basic test verification and enhancement • Add standard and custom verification points. • Enhance tests with parameters. • Add custom checkpoints. • Add database checkpoints. • Add bitmap checkpoints. • View test results.
11%	Modular automated test builds •Explain how to build modular QTP tests with Actions. •Use a Shared Object Repository.
7%	QTP and ALM integration •Explain the QTP/ALM connection. •Define ALM management of QTP resources. •Explain versioning features in QTP
10%	Automated test troubleshooting •Troubleshoot Object Recognition problems. •Use Recovery scenarios. •Use the Debugging Tool. •Measure System Performance. •Configure log tracking
4%	Advanced QTP Scripting • Import and export Excel sheets. • Get and set object properties. • Identify descriptive programming to bypass repository.
7%	Expert View • Describe Expert View features. • Describe dynamic object programming. • Identify and describe VBScript elements.
8%	Web applications • Recognize Web Add-in Extensibility. • Describe Web event recording use and configuration. • Identify new web testing capabilities.

How to enroll for QTP 11 certification?

Here are the steps you can follow to register for HP AIS – Functional Testing v11. Code for this exam is HP0-M47.

If you’re new to HP portal, you would first need to register on HP partner portal here. [In case you already have HP Passport credentials, you can login here.]
Click on the link depending upon your geographical location.
For this article purpose, let us click on United States. You will get the screen shown below. Click on ‘Register’ link.
In all probability, “You work for an HP Partner and want to register for this portal for the first time”. Click on Option A as shown below.
You will now get a two step registration form. You would need to fill your personal details on the first step and your company id on second step. (Check with your organizations training department for the company id). This step may vary depending upon the region you chose above.
Once done, you should get your registration confirmation within 2-3 business days.
Now login here and click the Home tab on top left side.
On the right hand side enter the search term HP AIS – Functional Testing v11 and follow the illustration below.
Scroll to the bottom. You can now download the exam preparation guide and click on the last link to register/login with Prometric.

How to prepare for QTP 11 certification?

To prepare for QTP 11 certification, you can take help of our high quality QTP Cert mock papers. These papers are developed by experts of QTP in collaboration with www.LearnQTP.com
QTP cert is a set of 348 questions. QTP Cert will not only help you ace QTP 11 certification exam but will also help you get a firm grasp over QTP concepts. We have invested a lot of time and energy to come up with these questions and have tried to incorporate almost all major concepts of QTP and syllabus of QTP 11 certification inside these papers.

VBScript Features

Windows Scripting 5.8

The following table is a list of Microsoft Visual Basic Scripting Edition (VBScript) features.

Features by Category

Category	Keywords
Array handling	Array, Dim, Erase, IsArray, LBound, Private, Public, ReDim, UBound
Assignments	Set
Comments	Comments using ' or Rem
Constants/Literals	Empty, False, Nothing, Null, True
Control flow	Do...Loop, For...Next, For Each...Next, If...Then...Else, Select Case, While...Wend, With
Conversions	Abs, Asc, AscB, AscW, CBool, CByte, CCur, CDate, CDbl, Chr, ChrB, ChrW, CInt, CLng, CSng, CStr, DateSerial, DateValue, Fix, Hex, Int, Oct, Sgn, TimeSerial, TimeValue
Dates/Times	Date, DateAdd, DateDiff, DatePart, DateSerial, DateValue, Day, Hour, Minute, Month, MonthName, Now, Second, Time, TimeSerial, TimeValue, Weekday, WeekdayName, Year
Declarations	Class, Const, Dim, Function, Private, Property Get, Property Let, Property Set, Public, ReDim, Sub
Error Handling	Err, On Error
Expressions	Eval, Execute, RegExp, Replace, Test
Formatting Strings	FormatCurrency, FormatDateTime, FormatNumber, FormatPercent
Input/Output	InputBox, LoadPicture, MsgBox
Literals	Empty, False, Nothing, Null, True
Math	Atn, Cos, Exp, Log, Randomize, Rnd, Sin, Sqr, Tan
Miscellaneous	Eval Function, Execute Statement, RGB Function
Objects	CreateObject, Err Object, GetObject, RegExp
Operators	Addition (+), And, Division (/), Equality (=), Eqv, Exponentiation (^), Greater Than (>), Greater Than or Equal To (>=), Imp, Inequality (<>), Integer Division (\), Is, Less Than (<), Less Than or Equal To (<=), Modulus arithmetic (Mod), Multiplication (*), Negation (-), Or, String concatenation (&), Subtraction (-), Xor
Options	Option Explicit
Procedures	Call, Function, Property Get, Property Let, Property Set, Sub
Rounding	Abs, Fix, Int, Round, Sgn
Script Engine ID	ScriptEngine, ScriptEngineBuildVersion, ScriptEngineMajorVersion, ScriptEngineMinorVersion
Strings	Asc, AscB, AscW, Chr, ChrB, ChrW, Filter, InStr, InStrB, InStrRev, Join, LCase, Len, LenB, Left, LeftB, LTrim, Mid, MidB, Replace, Right, RightB, RTrim, Space, Split, StrComp, String, StrReverse, Trim, UCase
Variants	IsArray, IsDate, IsEmpty, IsNull, IsNumeric, IsObject, TypeName, VarType

VBScript Fundamentals

Windows Scripting 5.8

The following sections explain the basic design of the VBScript language.

In This Section

VBScript Features

Lists VBScript features by category and links to a reference topic for each feature.

VBScript Data Types

Explains the data types available in VBScript and how to use them.

VBScript Variables

Explains the concept of variables in VBScript and illustrates how to use them.

VBScript Constants

Illustrates how to create constants in VBScript.

VBScript Operators

Lists the VBScript operators and links to a reference topic that explains each operator.

Using Conditional Statements

Illustrates how to create and use conditions in VBScript code.

Looping Through Code

Explains how to use the various looping mechanisms in VBScript.

VBScript Procedures

Describes how construct and use the various types of procedures in VBScript.

ByRef and ByVal Parameters

Explains the difference between passing parameters by reference and by value, and describes the ByRef and ByVal keywords.

Related Sections

VBScript Language Reference

Defines the elements of VBScript and provides syntax for proper use.

Variables and Constants

What is a Variable?
· Variable is a virtual Container/Placeholder where you store a desired information, called value, in the computer’s memory.
· To see or change its value, you refer it by its name.
· In VBScript, variables are always of one fundamental data type, Variant.

Types of Variable

· Scalar Variable
· Array Variables

Difference between Scalar variable and Array variable

The beauty of an array is that it enables you to store and use a series of data using one variable name and an index to distinguish the individual items. By using an index, you can often make your code simpler and more efficient so that it’s easier for you to put a script together and change it later. With VBScript, the elements inside your array can hold any kind of data. The elements don’t have to be all integers or all strings. Thus, an array can hold a combination of data types.

Scalar Variable

Naming Standards of a Var:

- MUST always begin with an alpha character

- MUST be a unique name in the scope in which it is declared

- MUST NOT exceed 255 characters

- MUST NOT have a period a character

- MUST NOT be the name of a keyword already used in VBScript.

Example 1: alpha, alpha123, alpha_123

Example 2: 123alpha, alpha.123, alpha.alpha, Date, Time,

Overriding Naming Standards

You can override standard variable naming conventions by placing your variable name in brackets. This allows you to use reserved words and/or illegal characters in variable names.

For example,

Dim [1st_name], [Date]

[1st_name] = “Jojo”

msgbox [1st_name]

[Date] = “October 2, 1962″

msgbox [Date]

msgbox Date

Assigning value to a variable

The variable name is to the left followed by an equality sign followed by the value.

<unique name> = <value>

Example 1:

Agent_Name = “jojo”

Num_Tickets = 3

Declaring Variables

• Explicit Declaration of a variable

Dim statement variable if declared at the script level are available to all procedures within the script. At the procedure level, variables are available only within the procedure.

Public statement variables are available to all procedures in all scripts.

Private statement variables are available only to the script in which they are declared.

Example:

Dim oUser_ID, oPassword

o User_ID = “jojo”

oPassword = “mercury”

• Implicit Declaration of a variable

You can also declare a variable implicitly by simply using its name in your script.

Like this,

User_ID = “jojo”

Note: This is not a good practice, as you can make a fat-finger mistake.

Example:

Dim UserID

UserID = “Jojo”

msgbox Usr_ID

Option Explicit Statement

• The Option Explicit statement forces explicit declaration of all variables in a script.

• The Option Explicit statement should be the first statement in your script.

Example:

Option Explicit

Dim User_ID

User_ID = “jojo”

msgbox Usr_ID

Array Variables

In situations where you have several variables, it can get very messy to declare and use the variables. A good example will be a grocery list. When you have several items, say around 50, it is difficult to assign each one to a variable. Instead, you must put all the variables, i.e. elements, in a super variable called Array. The count of item in an Array starts with 0.

Syntax:

Dim <Name of Array> (number of items in the array)

<Name of Array>(0) = <value_1>

<Name of Array>(1) = <value_2>

<Name of Array>(nth item) = <value_n>

Example:

Dim myArray(3)

myArray(0) = “Milk”

myArray(1) = “Bread”

myArray(2) = “Eggs”

myArray(3) = “Cookies”

Msgbox myArray(1)

This code would display “Bread”

Please note “myArray(3)” indicates that myArray has 4 elements.

Thus, a single variable, myArray, can assume four different values.

Constants

What are constants?

A constant is a variable within a program that never changes in value. Users can create their own constants by initializing variables accordingly and then not changing their value.

Declaring Constants

Constants perform a similar function to variables. Like variable they are a symbolic replacement for an item of data in memory. The difference is that a constant keeps the same value throughout its lifetime.

Values are assigned to constants using the same method used for variables, and can contain the same range of data subtypes. The accepted method of denoting a constant is to use all capitals for the name. In this case, the use of underscores improves their readability and is highly recommended.

You create user-defined constants in VBScript using the Const statement. Using the Const statement, you can create string or numeric constants with meaningful names and assign them literal values.

Example:

Const TEMPERATURE = 72

Const DEPART_DATE = “12/12/2007”

Const FIRST_NAME = “Jojo”

VBScript pre-defined constants

A number of useful constants you can use in your code are built into VBScript. Constants provide a convenient way to use specific values without actually having to remember the value itself. Using constants also makes your code more maintainable should the value of any constant ever change. Because these constants are already defined in VBScript, you don’t need to explicitly declare them in your code. Simply use them in place of the values they represent.

Color Constants: Defines eight basic colors that can be used in scripting.
Date and Time Constants: Defines date and time constants used by various date and time functions.
Date Format Constants: Defines constants used to format dates and times.
Miscellaneous Constants: Defines constants that don’t conveniently fit into any other category.
MsgBox Constants: Defines constants used in the MsgBox function to describe button visibility, labeling, behavior, and return values.
String Constants: Defines a variety of non-printable characters used in string manipulation.
Tristate Constants: Defines constants used with functions that format numbers.
VarType Constants: Defines the various Variant subtypes.

· Software testing

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing is something to see the software in negative way to find what is missing or not working according to expectations in the software. (By: Deepak Chennoria)
Software testing can be stated as the process of validating and verifying that a software program/application/product:

meets the requirements that guided its design and development;
works as expected; and
can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.
Different software development models will focus the test effort at different points in the development process. Newer development models, such as Agile, often employ test driven development and place an increased portion of the testing in the hands of the developer, before it reaches a formal team of testers. In a more traditional model, most of the test execution occurs after the requirements have been defined and the coding process has been completed.

Overview

Testing can never completely identify all the defects within software.Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oracles—principles or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.
Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.
A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed

History

The separation of debugging from testing was initially introduced by Glenford J. Myers in 1979. Although his attention was on breakage testing ("a successful test is one that finds a bug" it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Dave Gelperin and William C. Hetzel classified in 1988 the phases and goals in software testing in the following stages

Software testing topics

Scope

A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.

Functional vs non-functional testing

Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work".
Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or other performance, behavior under certain constraints, or security. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users.

Defects and failures

Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by the program designer.A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.
Software faults occur through the following processes. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure.^[16] Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new hardware platform, alterations in source data or interacting with different software. A single defect may result in a wide range of failure symptoms.

Finding faults early

It is commonly believed that the earlier a defect is found the cheaper it is to fix it.^[17] The following table shows the cost of fixing the defect depending on the stage it was found.^[18] For example, if a problem in the requirements is found only post-release, then it would cost 10–100 times more to fix than if it had already been found by the requirements review.

Cost to fix a defect		Time detected
Cost to fix a defect		Requirements	Architecture	Construction	System test	Post-release
Time introduced	Requirements	1×	3×	5–10×	10×	10–100×
	Architecture	-	1×	10×	15×	25–100×
	Construction	-	-	1×	10×	10–25×

Compatibility

A common cause of software failure (real or perceived) is a lack of compatibility with other application software, operating systems (or operating system versions, old or new), or target environments that differ greatly from the original (such as a terminal or GUI application intended to be run on the desktop now being required to become a web application, which must render in a web browser). For example, in the case of a lack of backward compatibility, this can occur because the programmers develop and test software only on the latest version of the target environment, which not all users may be running. This results in the unintended consequence that the latest work may not function on earlier versions of the target environment, or on older hardware that earlier versions of the target environment was capable of using. Sometimes such issues can be fixed by proactively abstracting operating system functionality into a separate program module or library.

Input combinations and preconditions

A very fundamental problem with software testing is that testing under all combinations of inputs and preconditions (initial state) is not feasible, even with a simple product.^[13]^[19] This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed to be versus what it is supposed to do)—usability, scalability, performance, compatibility, reliability—can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another.

Static vs. dynamic testing

There are many approaches to software testing. Reviews, walkthroughs, or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be (and unfortunately in practice often is) omitted. Dynamic testing takes place when the program itself is used for the first time (which is generally considered the beginning of the testing stage). Dynamic testing may begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). Typical techniques for this are either using stubs/drivers or execution from a debugger environment. For example, spreadsheet programs are, by their very nature, tested to a large extent interactively ("on the fly"), with results displayed immediately after each calculation or text manipulation.

Software verification and validation

Software testing is used in association with verification and validation:^[20]

Verification: Have we built the software right? (i.e., does it match the specification).
Validation: Have we built the right software? (i.e., is this what the customer wants).

The terms verification and validation are commonly used interchangeably in the industry; it is also common to see these two terms incorrectly defined. According to the IEEE Standard Glossary of Software Engineering Terminology:

Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.

The software testing team

Software testing can be done by software testers. Until the 1980s the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing,different roles have been established: manager, test lead, test designer, tester, automation developer, and test administrator.

Software quality assurance (SQA)

Though controversial, software testing is a part of the software quality assurance (SQA) process.In SQA, software process specialists and auditors are concerned for the software development process rather than just the artifacts such as documentation, code and systems. They examine and change the software engineering process itself to reduce the amount of faults that end up in the delivered software: the so-called defect rate.
What constitutes an "acceptable defect rate" depends on the nature of the software; A flight simulator video game would have much higher defect tolerance than software for an actual airplane.
Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies.
Software testing is a task intended to detect defects in software by contrasting a computer program's expected results with its actual results for a given set of inputs. By contrast, QA (quality assurance) is the implementation of policies and procedures intended to prevent defects from occurring in the first place.

Testing methods

The box approach

Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

White box testing

Main article: White box testing

White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these.

Types of white box testing

The following types of white box testing exist:

· API testing (application programming interface) - testing of the application using public and private APIs

· Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once)

· Fault injection methods - improving the coverage of a test by introducing faults to test code paths

· Mutation testing methods

· Static testing - White box testing includes all static testing

Test coverage

White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.^[22]

Two common forms of code coverage are:

· Function coverage, which reports on functions executed

· Statement coverage, which reports on the number of lines executed to complete the test

They both return a code coverage metric, measured as a percentage.

Black box testing

Main article: Black box testing

Black box testing treats the software as a "black box"—without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, exploratory testing and specification-based testing.

Specification-based testing: Specification-based testing aims to test the functionality of software according to the applicable requirements.Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case.

Specification-based testing is necessary, but it is insufficient to guard against certain risks.

Advantages and disadvantages: The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers do not. On the other hand, black box testing has been said to be "like a walk in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed. As a result, there are situations when (1) a tester writes many test cases to check something that could have been tested by only one test case, and/or (2) some parts of the back-end are not tested at all.

Therefore, black box testing has the advantage of "an unaffiliated opinion", on the one hand, and the disadvantage of "blind exploring", on the other.

Grey box testing

Grey box testing (American spelling: gray box testing) involves having knowledge of internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey box, because the input and output are clearly outside of the "black-box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. However, modifying a data repository does qualify as grey box, as the user would not normally be able to change the data outside of the system under test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages.

Testing levels

Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test. The main levels during the development process as defined by the SWEBOK guide are unit-, integration-, and system testing that are distinguished by the test target without implying a specific process model.Other test levels are classified by the testing objective.

Test target

Unit testing

Main article: Unit testing

Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors.
These types of tests are usually written by developers as they work on code (white-box style), to ensure that the specific function is working as expected. One function might have multiple tests, to catch corner cases or other branches in the code. Unit testing alone cannot verify the functionality of a piece of software, but rather is used to assure that the building blocks the software uses work independently of each other.

Integration testing

Main article: Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be localised more quickly and fixed.
Integration testing works to expose defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system.^[29]

System testing

Main article: System testing

System testing tests a completely integrated system to verify that it meets its requirements.^[30]

System integration testing

Main article: System integration testing

System integration testing verifies that a system is integrated to any external or third-party systems defined in the system requirements.^{[citation needed]}

Objectives of testing

Regression testing

Main article: Regression testing

Regression testing focuses on finding defects after a major code change has occurred. Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically, regressions occur as an unintended consequence of program changes, when the newly developed part of the software collides with the previously existing code. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. The depth of testing depends on the phase in the release process and the risk of the added features. They can either be complete, for changes added late in the release or deemed to be risky, to very shallow, consisting of positive tests on each feature, if the changes are early in the release or deemed to be of low risk.

Acceptance testing

Main article: Acceptance testing

Acceptance testing can mean one of two things:

A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression.
Acceptance testing is performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development.

Alpha testing

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.^[31]

Beta testing

Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.^{[citation needed]}

Non-functional testing

Special methods exist to test non-functional aspects of software. In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines. Various commercial non-functional testing tools are linked from the software fault injection page; there are also numerous open-source and free software tools available that perform non-functional testing.

Software performance testing and load testing

Performance testing is executed to determine how fast a system or sub-system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Load testing is primarily concerned with testing that can continue to operate under a specific load, whether that be large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing.
Volume testing is a way to test functionality. Stress testing is a way to test reliability. Load testing is a way to test performance. There is little agreement on what the specific goals of load testing are. The terms load testing, performance testing, reliability testing, and volume testing, are often used interchangeably.

Stability testing

Stability testing checks to see if the software can continuously function well in or above an acceptable period. This activity of non-functional software testing is often referred to as load (or endurance) testing.

Usability testing

Usability testing is needed to check if the user interface is easy to use and understand. It is concerned mainly with the use of the application.

Security testing

Security testing is essential for software that processes confidential data to prevent system intrusion by hackers.

Internationalization and localization

The general ability of software to be internationalized and localized can be automatically tested without actual translation, by using pseudolocalization. It will verify that the application still works, even after it has been translated into a new language or adapted for a new culture (such as different currencies or time zones).
Actual translation to human languages must be tested, too. Possible localization failures include:

Software is often localized by translating a list of strings out of context, and the translator may choose the wrong translation for an ambiguous source string.
Technical terminology may become inconsistent if the project is translated by several people without proper coordination or if the translator is imprudent.
Literal word-for-word translations may sound inappropriate, artificial or too technical in the target language.
Untranslated messages in the original language may be left hard coded in the source code.
Some messages may be created automatically at run time and the resulting string may be ungrammatical, functionally incorrect, misleading or confusing.
Software may use a keyboard shortcut which has no function on the source language's keyboard layout, but is used for typing characters in the layout of the target language.
Software may lack support for the character encoding of the target language.
Fonts and font sizes which are appropriate in the source language, may be inappropriate in the target language; for example, CJK characters may become unreadable if the font is too small.
A string in the target language may be longer than the software can handle. This may make the string partly invisible to the user or cause the software to crash or malfunction.
Software may lack proper support for reading or writing bi-directional text.
Software may display images with text that wasn't localized.
Localized operating systems may have differently-named system configuration files and environment variables and different formats for date and currency.

To avoid these and other localization problems, a tester who knows the target language must run the program with all the possible use cases for translation to see if the messages are readable, translated correctly in context and don't cause failures.

Destructive testing

Main article: Destructive testing

Destructive testing attempts to cause the software or a sub-system to fail, in order to test its robustness.

The testing process

Traditional CMMI or waterfall development model

A common practice of software testing is that testing is performed by an independent group of testers after the functionality is developed, before it is shipped to the customer.This practice often results in the testing phase being used as a project buffer to compensate for project delays, thereby compromising the time devoted to testing.Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes.

Further information: Capability Maturity Model Integration and Waterfall model

Agile or Extreme development model

In counterpoint, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process, unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes incrementally larger portions of the test suites. The test suites are continuously updated as new failure conditions and corner cases are discovered, and they are integrated with any regression tests that are developed. Unit tests are maintained along with the rest of the software source code and generally integrated into the build process (with inherently interactive tests being relegated to a partially manual build acceptance process). The ultimate goal of this test process is to achieve continuous deployment where software updates can be published to the public frequently.

A sample testing cycle

Although variations exist between organizations, there is a typical cycle for testing. The sample below is common among organizations employing the Waterfall development model.

Requirements analysis: Testing should begin in the requirements phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests work.
Test planning: Test strategy, test plan, testbed creation. Since many activities will be carried out during testing, a plan is needed.
Test development: Test procedures, test scenarios, test cases, test datasets, test scripts to use in testing software.
Test execution: Testers execute the software based on the plans and test documents then report any errors found to the development team.
Test reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.
Test result analysis: Or Defect Analysis, is done by the development team usually along with the client, in order to decide what defects should be treated, fixed, rejected (i.e. found software working properly) or deferred to be dealt with later.
Defect Retesting: Once a defect has been dealt with by the development team, it is retested by the testing team. AKA Resolution testing.
Regression testing: It is common to have a small test program built of a subset of tests, for each integration of new, modified, or fixed software, in order to ensure that the latest delivery has not ruined anything, and that the software product as a whole is still working correctly.
Test Closure: Once the test meets the exit criteria, the activities such as capturing the key outputs, lessons learned, results, logs, documents related to the project are archived and used as a reference for future projects.

Automated testing

Main article: Test automation

Many programming groups are relying more and more on automated testing, especially groups that use test-driven development. There are many frameworks to write tests in, and continuous integration software will run tests automatically every time code is checked into a version control system.
While automation cannot reproduce everything that a human can do (and all the ways they think of doing it), it can be very useful for regression testing. However, it does require a well-developed test suite of testing scripts in order to be truly useful.

Testing tools

Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as:

Program monitors, permitting full or partial monitoring of program code including:

Instruction set simulator, permitting complete instruction level monitoring and trace facilities
Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code
Code coverage reports

Formatted dump or symbolic debugging, tools allowing inspection of program variables on error or at chosen points
Automated functional GUI testing tools are used to repeat system-level tests through the GUI
Benchmarks, allowing run-time performance comparisons to be made
Performance analysis (or profiling tools) that can help to highlight hot spots and resource usage

Some of these features may be incorporated into an Integrated Development Environment (IDE).

A regression testing technique is to have a standard set of tests, which cover existing functionality that result in persistent tabular data, and to compare pre-change data to post-change data, where there should not be differences, using a tool like diffkit. Differences detected indicate unexpected functionality changes or "regression".

Measurement in software testing

Usually, quality is constrained to such topics as correctness, completeness, security, but can also include more technical requirements as described under the ISO standard ISO/IEC 9126, such as capability, reliability, efficiency, portability, maintainability, compatibility, and usability.
There are a number of frequently-used software measures, often called metrics, which are used to assist in determining the state of the software or the adequacy of the testing.

Testing artifacts

Software testing process can produce several artifacts.

Test plan

A test specification is called a test plan. The developers are well aware what test plans will be executed and this information is made available to management and the developers. The idea is to make them more cautious when developing their code or making additional changes. Some companies have a higher-level document called a test strategy.

Traceability matrix

A traceability matrix is a table that correlates requirements or design documents to test documents. It is used to change tests when the source documents are changed, or to verify that the test results are correct.

Test case

A test case normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result.This can be as pragmatic as 'for condition x your derived result is y', whereas other test cases described in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or expected outcome. The optional fields are a test case ID, test step, or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results, who generated the results, and what system configuration was used to generate those results. These past results would usually be stored in a separate table.

Test script

The test script is procedure, or a programing code that replicate the user actions. Initially the term was derived from the product of work created by automated regression test tools. Test Case will be a baseline to create test scripts using a tool or a program.

Test suite

The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests.

Test data

In most cases, multiple sets of values or data are used to test the same functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project.

Test harness

The software, tools, samples of data input and output, and configurations are all referred to collectively as a test harness.

Certifications

Several certification programs exist to support the professional aspirations of software testers and quality assurance specialists. No certification currently offered actually requires the applicant to demonstrate the ability to test software. No certification is based on a widely accepted body of knowledge. This has led some to declare that the testing field is not ready for certification. Certification itself cannot measure an individual's productivity, their skill, or practical knowledge, and cannot guarantee their competence, or professionalism as a tester.

Software testing certification types

· Exam-based: Formalized exams, which need to be passed; can also be learned by self-study [e.g., for ISTQB or QAI]

· Education-based: Instructor-led sessions, where each course has to be passed [e.g., International Institute for Software Testing (IIST)].

Testing certifications

· Certified Associate in Software Testing (CAST) offered by the QAI

· CATe offered by the International Institute for Software Testing

· Certified Manager in Software Testing (CMST) offered by the QAI

· Certified Software Tester (CSTE) offered by the Quality Assurance Institute (QAI)

· Certified Software Test Professional (CSTP) offered by the International Institute for Software Testing

· CSTP (TM) (Australian Version) offered by K. J. Ross & Associates^[45]

· ISEB offered by the Information Systems Examinations Board

· ISTQB Certified Tester, Foundation Level (CTFL) offered by the International Software Testing Qualification Board ^[46]^[47]

· ISTQB Certified Tester, Advanced Level (CTAL) offered by the International Software Testing Qualification Board

· TMPF TMap Next Foundation offered by the Examination Institute for Information Science

· TMPA TMap Next Advanced offered by the Examination Institute for Information Science

Quality assurance certifications

· CMSQ offered by the Quality Assurance Institute (QAI).

· CSQA offered by the Quality Assurance Institute (QAI)

· CSQE offered by the American Society for Quality (ASQ)

· CQIA offered by the American Society for Quality (ASQ)

Controversy

Some of the major software testing controversies include:

What constitutes responsible software testing?

Members of the "context-driven" school of testingbelieve that there are no "best practices" of testing, but rather that testing is a set of skills that allow the tester to select or invent testing practices to suit each unique situation.

Agile vs. traditional

Should testers learn to work under conditions of uncertainty and constant change or should they aim at process "maturity"? The agile testing movement has received growing popularity since 2006 mainly in commercial circles,whereas government and militarysoftware providers use this methodology but also the traditional test-last models (e.g. in the Waterfall model).^[^{citation needed}^]

Exploratory test vs. scripted

Should tests be designed at the same time as they are executed or should they be designed beforehand?

Manual testing vs. automated

Some writers believe that test automation is so expensive relative to its value that it should be used sparingly.More in particular, test-driven development states that developers should write unit-tests of the XUnit type before coding the functionality. The tests then can be considered as a way to capture and implement the requirements.

Software design vs. software implementation

Should testing be carried out only at the end or throughout the whole process?

Who watches the watchmen?

The idea is that any form of observation is also an interaction—the act of testing can also affect that which is being tested.

Acceptance testing

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests
In systems engineering it may involve black-box testing performed on a system (for example: a piece of software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery.^[1] It is also known as functional testing, black-box testing, QA testing, application testing, confidence testing, final testing, validation testing, or factory acceptance testing.
Software developers often distinguish acceptance testing by the system provider from acceptance testing by the customer (the user or client) prior to accepting transfer of ownership. In the case of software, acceptance testing performed by the customer is known as user acceptance testing (UAT), end-user testing, site (acceptance) testing, or field (acceptance) testing.
A smoke test is used as an acceptance test prior to introducing a build to the main testing process.

Test automation

From Wikipedia, the free encyclopedia

(Redirected from Automated testing)

It has been suggested that this article or section be merged with Test execution engine. (Discuss) Proposed since February 2010.

It has been suggested that this article or section be merged with Test automation framework. (Discuss) Proposed since March 2010.

Compare with Manual testing.

Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.

Overview

Although manual tests may find many defects in a software application, it is a laborious and time consuming process. In addition, it may not be effective in finding certain classes of defects. Test automation is a process of writing a computer program to do testing that would otherwise need to be done manually. Once tests have been automated, they can be run quickly and repeatedly. This is often the most cost effective method for software products that have a long maintenance life, because even minor patches over the lifetime of the application can cause features to break which were working at an earlier point in time.
There are two general approaches to test automation:

Code-driven testing. The public (usually) interfaces to classes, modules, or libraries are tested with a variety of input arguments to validate that the results that are returned are correct.
Graphical user interface testing. A testing framework generates user interface events such as keystrokes and mouse clicks, and observes the changes that result in the user interface, to validate that the observable behavior of the program is correct.

Test automation tools can be expensive, and it is usually employed in combination with manual testing. It can be made cost-effective in the longer term, especially when used repeatedly in regression testing.
One way to generate test cases automatically is model-based testing through use of a model of the system for test case generation but research continues into a variety of alternative methodologies for doing so.
What to automate, when to automate, or even whether one really needs automation are crucial decisions which the testing (or development) team must make. Selecting the correct features of the product for automation largely determines the success of the automation. Automating unstable features or features that are undergoing changes should be avoided.^[2]

Code-driven testing

A growing trend in software development is the use of testing frameworks such as the xUnit frameworks (for example, JUnit and NUnit) that allow the execution of unit tests to determine whether various sections of the code are acting as expected under various circumstances. Test cases describe tests that need to be run on the program to verify that the program runs as expected.
Code driven test automation is a key feature of Agile software development, where it is known as Test-driven development (TDD). Unit tests are written to define the functionality before the code is written. Only when all tests pass is the code considered complete. Proponents argue that it produces software that is both more reliable and less costly than code that is tested by manual exploration. It is considered more reliable because the code coverage is better, and because it is run constantly during development rather than once at the end of a waterfall development cycle. The developer discovers defects immediately upon making a change, when it is least expensive to fix. Finally, code refactoring is safer; transforming the code into a simpler form with less code duplication, but equivalent behavior, is much less likely to introduce new defects.

Graphical User Interface (GUI) testing

Many test automation tools provide record and playback features that allow users to interactively record user actions and replay them back any number of times, comparing actual results to those expected. The advantage of this approach is that it requires little or no software development. This approach can be applied to any application that has a graphical user interface. However, reliance on these features poses major reliability and maintainability problems. Relabelling a button or moving it to another part of the window may require the test to be re-recorded. Record and playback also often adds irrelevant activities or incorrectly records some activities.
A variation on this type of tool is for testing of web sites. Here, the "interface" is the web page. This type of tool also requires little or no software development. However, such a framework utilizes entirely different techniques because it is reading HTML instead of observing window events.
Another variation is scriptless test automation that does not use record and playback, but instead builds a model of the application under test and then enables the tester to create test cases by simply editing in test parameters and conditions. This requires no scripting skills, but has all the power and flexibility of a scripted approach. Test-case maintenance is easy, as there is no code to maintain and as the application under test changes the software objects can simply be re-learned or added. It can be applied to any GUI-based software application.

What to test

Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging, etc., without necessarily automating tests in an end-to-end fashion.
One must keep satisfying popular requirements when thinking of test automation:

Platform and OS independence
Data driven capability (Input Data, Output Data, Metadata)
Customizable Reporting (DB Access, crystal reports)
Easy debugging and logging
Version control friendly – minimal binary files
Extensible & Customizable (Open APIs to be able to integrate with other tools)
Common Driver (For example, in the Java development ecosystem, that means Ant or Maven and the popular IDEs). This enables tests to integrate with the developers' workflows.
Support unattended test runs for integration with build processes and batch runs. Continuous Integration servers require this.
Email Notifications (automated notification on failure or threshold levels). This may be the test runner or tooling^{[clarification needed]} that executes it.
Support distributed execution environment (distributed test bed)
Distributed application support (distributed SUT)

Framework approach in automation

A framework is an integrated system that sets the rules of Automation of a specific product. This system integrates the function libraries, test data sources, object details and various reusable modules. These components act as small building blocks which need to be assembled to represent a business process. The framework provides the basis of test automation and simplifies the automation effort.

Defining boundaries between automation framework and a testing tool

Tools are specifically designed to target some particular test environment. Such as: Windows automation tool, web automation tool etc. It serves as driving agent for an automation process. However, automation framework is not a tool to perform some specific task, but is an infrastructure that provides the solution where different tools can plug itself and do their job in a unified manner. Hence providing a common platform to the automation engineer doing their job.
There are various types of frameworks. They are categorized on the basis of the automation component they leverage. These are:

Notable test automation tools

Tool name	Produced by	Latest version
TestDrive	Original Software	7.0
HP QuickTest Professional	HP	11.0
IBM Rational Functional Tester	IBM Rational	8.2.0.2
Parasoft SOAtest	Parasoft	9.0
QF-Test	Quality First Software GmbH	3.4.1
Ranorex	Ranorex GmbH	3.0
Rational robot	IBM Rational	2003
Selenium	Open source	1.0.10
HTTP Test Tool	Open source	2.0.8
SilkTest	Micro Focus	2010 R2 WS2
TestArchitect	LogiGear	6.0
TestComplete	SmartBear Software	8.5
Testing Anywhere	Automation Anywhere	7.0
TestPartner	Micro Focus	6.3
TOSCA Testsuite	TRICENTIS Technology & Consulting	7.3.0
Visual Studio Test Professional	Microsoft	2010
WATIR	Open source	1.6.5
WebUI Test Studio	Telerik, Inc.	2011.1

Manual testing

From Wikipedia, the free encyclopedia

Compare with Test automation.

Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user, and use most of all features of the application to ensure correct behavior. To ensure completeness of testing, the tester often follows a written test plan that leads them through a set of important test cases.

Overview

A key step in the process of software engineering is testing the software for correct behavior prior to release to end users.
For small scale engineering efforts (including prototypes), exploratory testing may be sufficient. With this informal approach, the tester does not follow any rigorous testing procedure, but rather explores the user interface of the application using as many of its features as possible, using information gained in prior tests to intuitively derive additional tests. The success of exploratory manual testing relies heavily on the domain expertise of the tester, because a lack of knowledge will lead to incompleteness in testing. One of the key advantages of an informal approach is to gain an intuitive insight to how it feels to use the application.
Large scale engineering projects that rely on manual software testing follow a more rigorous methodology in order to maximize the number of defects that can be found. A systematic approach focuses on predetermined test cases and generally involves the following steps.

Choose a high level test plan where a general methodology is chosen, and resources such as people, computers, and software licenses are identified and acquired.
Write detailed test cases, identifying clear and concise steps to be taken by the tester, with expected outcomes.
Assign the test cases to testers, who manually follow the steps and record the results.
Author a test report, detailing the findings of the testers. The report is used by managers to determine whether the software can be released, and if not, it is used by engineers to identify and correct the problems.

A rigorous test case based approach is often traditional for large software engineering projects that follow a Waterfall model. However, at least one recent study did not show a dramatic difference in defect detection efficiency between exploratory testing and test case based testing.

Stages

There are several stages. They are
Unit Testing This initial stage in testing normally carried out by the developer who wrote the code and sometimes by a peer using the white box testing technique.
Integration Testing This stage is carried out in two modes, as a complete package or as a increment to the earlier package. Most of the time black box testing technique is used. However, sometimes a combination of Black and White box testing is also used in this stage.
System Testing In this stage the software is tested from all possible dimensions for all intended purposes and platforms. In this stage Black box testing technique is normally used.
User Acceptance Testing This testing stage carried out in order to get customer sign-off of finished product. A 'pass' in this stage also ensures that the customer has accepted the software and is ready for their use.

Comparison to Automated Testing

Test automation may be able to reduce or eliminate the cost of actual testing. A computer can follow a rote sequence of steps more quickly than a person, and it can run the tests overnight to present the results in the morning. However, the labor that is saved in actual testing must be spent instead authoring the test program. Depending on the type of application to be tested, and the automation tools that are chosen, this may require more labor than a manual approach. In addition, some testing tools present a very large amount of data, potentially creating a time consuming task of interpreting the results. From a cost-benefit perspective, test automation becomes more cost effective when the same tests can be reused many times over, such as for regression testing and test-driven development, and when the results can be interpreted quickly. If future reuse of the test software is unlikely, then a manual approach is preferred.
Things such as device drivers and software libraries must be tested using test programs. In addition, testing of large numbers of users (performance testing and load testing) is typically simulated in software rather than performed in practice.
Conversely, graphical user interfaces whose layout changes frequently are very difficult to test automatically. There are test frameworks that can be used for regression testing of user interfaces. They rely on recording of sequences of keystrokes and mouse gestures, then playing them back and observing that the user interface responds in the same way every time. Unfortunately, these recordings may not work properly when a button is moved or relabeled in a subsequent release. An automatic regression test may also be fooled if the program output varies significantly (e.g. the display includes the current system time). In cases such as these, manual testing may be more effective

http://www.slideshare.net/mehramit/qtp-basics (this site is beautiful)

make sure u like : do same like that

1. What is Test automation

· Software test automation is the process of automating the steps of manual test cases using an automation tool or utility or shorten the testing life cycle with respect to time

· When application undergoes regression, some of the steps might be missed out or skipped which can be avoided in automation

· Automation helps to avoid human errors also expedite the testing process

· To implement the test automation detailed planning and effort is required

2. Automation fundamental concepts :

· Automation saves time and effort which results in reduction of the test life cycle

Benefits of automation:

· Consistency of Test execution

· Reducing cycle time of regression test cycle

· Data driven testing

· Repeatability

· Coverage

· Reliability

· Reusability of test wares

§ Automation life cycle is subset of the entire life cycle

§ Automation planning can be initiated to parallel the test planning phase

§ Factors to be considered in automation planning ,

· Stability of AUT (Application under test)

· No of regression cycle to be performed

· Compatibility of application platform with testing tools

· Cost benefit analysis (ROI)

· Availability of skilled resources

3. Regression testing & Automation

When automation is applicable?

· Regression life cycles are long and iterative

· Test repeatability is required

4. Testing process with QTP

Creating Test scripts à Running tests à Analyzing test results

Test planning Skills

Test Planning

This is the phase where Project Manager has to decide what things need to be tested,do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.

Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.

In Test Planning following are the major tasks: 1. Defining scope of testing 2. Identification of approaches 3. Defining risk 4. Identifying resources 5. Defining Time Schedule

[edit]Test Analysis

Once test plan is made and decided upon, next step is to deal a little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing,;,

Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats andtest cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance Testing.

[edit]Test Design

Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared.

[edit]Construction and verification

In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.

[edit]Testing Cycles

In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).

[edit]Final Testing and Implementation

In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.

[edit]Post Implementation

In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines are restored to base lines in this stage.

==Software Testing Life Cycle==h Phase Activities Outcome Planning Create high level test plan Test plan, Refined Specification Analysis

Create detailed test plan, Functional Validation Matrix, test cases

Revised Test Plan, Functional validation matrix, test cases

Design

test cases are revised; select which test cases to automate

revised test cases, test data sets, sets, risk assessment sheet

Construction

scripting of test cases to automate,

test procedures/Scripts, Drivers, test results, Bugreports.

Testing cycles complete testing cycles Test results, Bug Reports Final testing execute remaining stress and performance tests, complete documentation Test results and different metrics on test efforts Post implementation Evaluate testing processes Plan for improvement of testing process

Software testing lifecycle is a systematic approach towards the sequence of activities conducted during Testing phase. 1.Test Planning 2.Test Development 3.Test Execution 4.Result Analysis 5.Bug Tracking 6.Reporting.

STLS

Contrary to popular belief, Software Testing is not a just a single activity. It consists of series of activities carried out methodologically to help certify your software product. These activities (stages) constitute the Software Testing Life Cycle (STLC).

The different stages in Software Test Life Cycle -

Each of these stages have a definite Entry and Exit criteria , Activities & Deliverables associated with it.

In an Ideal world you will not enter the next stage until the exit criteria for the previous stage is met. But practically this is not always possible. So for this tutorial , we will focus of activities and deliverables for the different stages in STLC. Lets look into them in detail.

Requirement Analysis

During this phase, test team studies the requirements from a testing point of view to identify the testable requirements. The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail. Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ) .Automation feasibility for the given testing project is also done in this stage.

Activities

· Identify types of tests to be performed.

· Gather details about testing priorities and focus.

· Prepare Requirement Traceability Matrix (RTM).

· Identify test environment details where testing is supposed to be carried out.

· Automation feasibility analysis (if required).

Deliverables

· RTM

· Automation feasibility report. (if applicable)

Test Planning

This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager will determine effort and cost estimates for the project and would prepare and finalize the Test Plan.

Activities

· Preparation of test plan/strategy document for various types of testing

· Test tool selection

· Test effort estimation

· Resource planning and determining roles and responsibilities.

· Training requirement

Deliverables

· Test plan /strategy document.

· Effort estimation document.

Test Case Development

This phase involves creation, verification and rework of test cases & test scripts. Test data , is identified/created and is reviewed and then reworked as well.

Activities

· Create test cases, automation scripts (if applicable)

· Review and baseline test cases and scripts

· Create test data (If Test Environment is available)

Deliverables

· Test cases/scripts

· Test data

Test Environment Setup

Test environment decides the software and hardware conditions under which a work product is tested. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment.

Activities

· Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment.

· Setup test Environment and test data

· Perform smoke test on the build

Deliverables

· Environment ready with test data set up

· Smoke Test Results.

Test Execution

During this phase test team will carry out the testing based on the test plans and the test cases prepared. Bugs will be reported back to the development team for correction and retesting will be performed.

Activities

· Execute tests as per plan

· Document test results, and log defects for failed cases

· Map defects to test cases in RTM

· Retest the defect fixes

· Track the defects to closure

Deliverables

· Completed RTM with execution status

· Test cases updated with results

· Defect reports

Test Cycle Closure

Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future.

Activities

· Evaluate cycle completion criteria based on Time,Test coverage,Cost,Software,Critical Business Objectives , Quality

· Prepare test metrics based on the above parameters.

· Document the learning out of the project

· Prepare Test closure report

· Qualitative and quantitative reporting of quality of the work product to the customer.

· Test result analysis to find out the defect distribution by type and severity.

Deliverables

· Test Closure report

· Test metrics

Finally, summary of STLC along with Entry and Exit Criteria

STLC Stage	Entry Criteria	Activity	Exit Criteria	Deliverables
Requirement Analysis	Requirements Document available (both functional and non functional) Acceptance criteria defined. Application architectural document available.	Analyse business functionality to know the business modules and module specific functionalities. Identify all transactions in the modules. Identify all the user profiles. Gather user interface/authentication, geographic spread requirements. Identify types of tests to be performed. Gather details about testing priorities and focus. Prepare Requirement Traceability Matrix (RTM). Identify test environment details where testing is supposed to be carried out. Automation feasibility analysis (if required).	Signed off RTM Test automation feasibility report signed off by the client	RTM Automation feasibility report (if applicable)
Test Planning	Requirements Documents Requirement Traceability matrix. Test automation feasibility document.	Analyze various testing approaches available Finalize on the best suited approach Preparation of test plan/strategy document for various types of testing Test tool selection Test effort estimation Resource planning and determining roles and responsibilities.	Approved test plan/strategy document. Effort estimation document signed off.	Test plan/strategy document. Effort estimation document.
Test case development	Requirements Documents RTM and test plan Automation analysis report	Create test cases, automation scripts (where applicable) Review and baseline test cases and scripts Create test data	Reviewed and signed test Cases/scripts Reviewed and signed test data	Test cases/scripts Test data
Test Environment setup	System Design and architecture documents are available Environment set-up plan is available	Understand the required architecture, environment set-up Prepare hardware and software requirement list Finalize connectivity requirements Prepare environment setup checklist Setup test Environment and test data Perform smoke test on the build Accept/reject the build depending on smoke test result	Environment setup is working as per the plan and checklist Test data setup is complete Smoke test is successful	Environment ready with test data set up Smoke Test Results.
Test Execution	Baselined RTM, Test Plan , Test case/scripts are available Test environment is ready Test data set up is done Unit/Integration test report for the build to be tested is available	Execute tests as per plan Document test results, and log defects for failed cases Update test plans/test cases, if necessary Map defects to test cases in RTM Retest the defect fixes Regression testing of application Track the defects to closure	All tests planned are executed Defects logged and tracked to closure	Completed RTM with execution status Test cases updated with results Defect reports
Test Cycle closure	Testing has been completed Test results are available Defect logs are available	Evaluate cycle completion criteria based on - Time, Test coverage , Cost , Software Quality , Critical Business Objectives Prepare test metrics based on the above parameters. Document the learning out of the project Prepare Test closure report Qualitative and quantitative reporting of quality of the work product to the customer. Test result analysis to find out the defect distribution by type and severity	Test Closure report signed off by client	Test Closure report Test metrics

Bug life cycle

What is Bug/Defect?

Simple Wikipedia definition of Bug is: “A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.”

Other definitions can be:
An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction.

or
A fault in a program, which causes the program to perform in an unintended or unanticipated manner.

Lastly the general definition of bug is: “failure to conform to specifications”.

If you want to detect and resolve the defect in early development stage, defect tracking and software development phases should start simultaneously.

We will discuss more on Writing effective bug report in another article. Let’s concentrate here on bug/defect life cycle.

Life cycle of Bug:

1) Log new defect
When tester logs any new bug the mandatory fields are:
Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce

In above list you can add some optional fields if you are using manual Bug submission template:
These Optional Fields are: Customer name, Browser, Operating system, File Attachments or screenshots.

The following fields remain either specified or blank:
If you have authority to add bug Status, Priority and ‘Assigned to’ fields them you can specify these fields. Otherwise Test manager will set status, Bug priority and assign the bug to respective module owner.

Look at the following Bug life cycle:

[See the image on bug-life-cycle1image.jpg] Ref: Bugzilla bug life cycle

The figure is quite complicated but when you consider the significant steps in bug life cycle you will get quick idea of bug life.

On successful logging the bug is reviewed by Development or Test manager. Test manager can set the bug status as Open, can Assign the bug to developer or bug may be deferred until next release.

When bug gets assigned to developer and can start working on it. Developer can set bug status as won’t fix, Couldn’t reproduce, Need more information or ‘Fixed’.

If the bug status set by developer is either ‘Need more info’ or Fixed then QA responds with specific action. If bug is fixed then QA verifies the bug and can set the bug status as verified closed or Reopen.

Bug status description:
These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using.

1) New: When QA files new bug.

2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.

3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.

4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

6) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.

9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

Monday, 7 November 2011

QTP

Are you sure you want to use QTP?

Some Useful Tips with QTP

Installing QTP’s trial version

QTP Testing Process

Explain Test object Model, test object and run-time object ?

Object Repositories in QTP 9 (QuickTest Professional)

Checkpoints in QTP

QTP (QuickTest Professional) Recording

Parameterizing Tests in QTP (QuickTest Professional)

QTP (QuickTest Professional) keyword view

VBScript in QTP

Actions in QTP 9 (QuickTest Professional)

What is VBScript?

How Does it Work?

Details on QTP 11 Certification (HP0-M47)

What are the major changes between QTP 10.0 certification exam and QTP 11.0 certification exam?

What to expect in HP0-M47: HP QuickTest Professional 11.0 exam?

What is the syllabus for QTP 11 certification exam?

How to enroll for QTP 11 certification?

How to prepare for QTP 11 certification?

VBScript Features

VBScript Fundamentals

Overview

History

Software testing topics

Scope

Functional vs non-functional testing

Defects and failures

Finding faults early

Compatibility

Input combinations and preconditions

Static vs. dynamic testing

Software verification and validation

The software testing team

Software quality assurance (SQA)

Testing methods

The box approach

White box testing

Black box testing

Grey box testing

Testing levels

Test target

Unit testing

Integration testing

System testing

System integration testing

Objectives of testing

Regression testing

Acceptance testing

Alpha testing

Beta testing

Non-functional testing

Software performance testing and load testing

Stability testing

Usability testing

Security testing

Internationalization and localization

Destructive testing

The testing process

Traditional CMMI or waterfall development model

Agile or Extreme development model

A sample testing cycle

Automated testing

Testing tools

Measurement in software testing

Testing artifacts

Certifications

Controversy

Test automation

Contents

Overview

Code-driven testing

Graphical User Interface (GUI) testing

What to test

Framework approach in automation

Defining boundaries between automation framework and a testing tool

Notable test automation tools

Manual testing