QUICK TEST PROFESSIONALS

Reckless Assumption - We can automate testing actions

2010-06-29T02:39:00.000-07:00

We can automate testing actions:

Some tasks that are easy for people are hard for computers. Probably the hardest part of automation is interpreting test results. For GUI software, it is very hard to automatically notice all categories of significant problems while ignoring the insignificant problems.

The problem of automatability is compounded by the high degree of uncertainty and change in a typical innovative software project. In market driven software projects it's common to use an incremental development approach, which pretty much guarantees that the product will change, in fundamental ways, until quite late in the project. This fact, coupled with the typical absence of
complete and accurate product specifications, make automation development something like driving through a trackless forest in the family sedan: you can do it, but you'll have to go slow, you'll do a lot of backtracking, and you might get stuck.

Even if we have a particular sequence of operations that can in principle be automated, we can only do so if we have an appropriate tool for the job. Information about tools is hard to come by, though, and the most critical aspects of a regression test tool are impossible to evaluate unless we create or review an industrial size test suite using the tool. Here are some of the factors to consider when selecting a test tool. Notice how many of them could never be evaluated just by perusing the users manual or watching a trade show demo:

♦ Capability: Does the tool have all the critical features we need, especially in the area of test result validation and test suite management?

♦ Reliability: Does the tool work for long periods without failure, or is it full of bugs? Many test tools are developed by small companies that do a poor job of testing them.

♦ Capacity: Beyond the toy examples and demos, does the tool work without failure in an industrial environment? Can it handle large scale test suites that run for hours or days and involve thousands of scripts?

♦ Learnability: Can the tool be mastered in a short time? Are there training classes or books available to aid that process?

♦ Operability: Are the features of the tool cumbersome to use, or prone to user error?

♦ Performance: Is the tool quick enough to allow a substantial savings in test development and execution time versus hand testing.

♦ Compatibility: Does the tool work with the particular technology that we need to test?

♦ Non-Intrusiveness: How well does the tool simulate an actual user? Is the behavior of the software under test the same with automation as without?

Reckless Assumption - Testing is a "sequence of actions"

2010-06-29T02:33:00.000-07:00

A more useful way to think about testing is as a sequence of interactions interspersed with evaluations. Some of those interactions are predictable, and some of them can be specified in purely objective terms. However, many others are complex, ambiguous, and volatile. Although it is often useful to conceptualize a general sequence of actions that comprise a given test, if we try to reduce testing to a rote series of actions the result will be a narrow and shallow set of tests.

Manual testing, on the other hand, is a process that adapts easily to change and can cope with complexity. Humans are able to detect hundreds of problem patterns, in a glance, an instantly distinguish them from harmless anomalies. Humans may not even be aware of all the evaluation that they are doing, but in a mere "sequence of actions" every evaluation must be explicitly planned. Testing may seem like just a set of actions, but good testing is an interactive cognitive process. That's why automation is best applied only to a narrow spectrum of testing, not to the majority of the test process. If you set out to automate all the necessary test execution, you'll probably spend a lot of money and time creating relatively weak tests that ignore many interesting bugs, and find many "problems" that turn out to be merely unanticipated correct behavior.

Scope of variables qtp frame work

2009-06-05T00:49:00.001-07:00

Mainly there are two types of variables: action parameters and environment variables.

An action's parameters are stored with the action and are the same for all calls to that action. If you change the action parameters defined for an action, and then view the action properties for a call to that same action in a different part of the test, you can see the action parameters have changed. However, the actual values specified for input action parameters and the locations specified for action output parameters can be different for each call to the action. When you insert a call to a copy of an action, the copy of the action is inserted with the action parameters and action call parameter values that were defined for the action you copied. When you split an action, the action parameters are copied to both actions. The action call values for the second action are taken from the default values of that action's parameters.

Environment variables can be accessed from your test. Throughout the test run, the value of an environment variable remains the same, regardless of the number of iterations, unless you change the value of the variable programmatically in your script.

There are three types of environment variables:

User-Defined Internal—variables that you define within the test. These variables are saved with the test and are accessible only within the test in which they were defined.

You can create or modify internal, user-defined environment variables for your test in the Environment tab of the Test Settings dialog box or in the Parameter Options dialog box.

User-Defined External—variables that you predefine in the active external environment variables file. You can create as many files as you want and select an appropriate file for each test, or change files for each test run. Note that external environment variable values are designated as read-only within the test.

Built-in—variables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. These variables are accessible from all tests, and are designated as read-only.

Functional testing of web applications with Selenium

2009-06-03T02:20:00.000-07:00

Functional testing and black box is a methodology used to test the behavior that has an application from the viewpoint of their functions, validated for this purpose various aspects ranging from the aesthetics of the front end, the navigation within your pages between pages within the forms, the compliance of technical specifications associated with fields, buttons, bars, among other pages, entry permits and access to consultations and modifications, management of parameters, the management of the modules that constitute , and other conditions that make up the various "features" expected to provide the system to operate the end user as a normal and correct.

To meet this objective, the tester must choose a set of inputs under certain pre-defined within a certain context, and to check whether the outputs are correct or incorrect depending on the outcome defined in advance between the parties and / or techniques for the customer / supplier.

This form of testing an application is made "outside", that is why "black box testing" because the test covers the roads that follow the internal procedures of the program.

In connection with this test, although there are many tools now that this one out for various reasons will be published in future articles is: Selenium.

Selenium works directly on the web browser, its installation is simple and handling is so intuitive that allows quickly define and configure a test case, recording the journey in a page and then save the sequence of steps as a test script and and then play it when you want.

Selenium is an open-source tool that not only allows the testing of the system but also facilitates the acceptance testing of web applications.

Integrates with Firefox, and includes the ability to write the tests directly in Java, C #, Python and Ruby.

This solution has three basic tools to record a sequence of steps within a website, simulate the test with different browsers and automated test generation.

Selenium IDE is a plugin for Firefox which allows you to record and execute scripts directly from your browser.

Selenium RC is a library and server written in Java that allows you to run scripts from local or remote through commands.

Grids Selenium: Selenium server allows multiple coordinate in order to run scripts on multiple platforms and devices at the same time.

Variable passing from one Action to another

2009-05-21T21:00:00.000-07:00

Variable passing from one Action to another

QuickTest enables you to retrieve values in your test or component and to store them as output values. You can subsequently retrieve these values and use them as input at a different stage in the run session. You can pass variables from one action to another by setting Action Call Parameter Values. You use the Parameter Values tab of the Action Call Properties dialog box to specify the values of input action parameters used by the called action and to specify the locations in which you want to store output action parameter values. You can also parameterize the value used for a particular input action parameter using any available parameter type.

The actual input and output action parameters that an action can receive or return, and their types, are defined in the Action Properties dialog box. If you do not set a value for an input action parameter in the Action Call Properties dialog box, the default value that is specified in the Action Properties dialog box is used.

You can specify a location in which to store the output action parameter values, which can be used in the called action.

To specify a location in which to store an output action parameter value:

In the Output parameters area, click in the Store In box for the parameter and enter a variable name.

If we choose variable to store the value, then the value is stored in a run-time variable for the duration of the run session. You can accept the default name assigned to the variable or enter a different variable name.
Alternatively, you can click the output storage button in the Store In box to open the Storage Location Options dialog box in which you can specify a location for storing the output value. You can select to store the value in a test or action parameter, a Data Table parameter, or an environment parameter.

Repeat this procedure for each output action parameter value in the list.

QTP Frame Work - Environment Variables

2009-05-21T20:58:00.000-07:00

Environment Variables

QuickTest can insert a value from the Environment variable list, which is a list of variables and corresponding values that can be accessed from your test. Throughout the test run, the value of an environment variable remains the same, regardless of the number of iterations, unless you change the value of the variable programmatically in your script.

There are three types of environment variables:

User-Defined Internal—variables that you define within the test. These variables are saved with the test and are accessible only within the test in which they were defined.

You can create or modify internal, user-defined environment variables for your test in the Environment tab of the Test Settings dialog box or in the Parameter Options dialog box.

Tip: You can also create environment output values, which retrieve values during the test run and output them to internal environment variable parameters for use in your test.

User-Defined External—variables that you predefine in the active external environment variables file. You can create as many files as you want and select an appropriate file for each test, or change files for each test run. Note that external environment variable values are designated as read-only within the test.

Built-in—variables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. These variables are accessible from all tests, and are designated as read-only.

Note: QuickTest also has a set of predefined environment variables that you can use to set the values of the Record and Run Settings dialog options. You should not use the names of these variables for any other purpose.

QTP frame work - Test Parameters

2009-05-17T21:55:00.000-07:00

In the Parameters tab of Test Settings, you can define input parameters that pass values into your test or component and output parameters that pass values from your test or

component to external sources. You can also use the Parameters tab to modify or delete existing test or component parameters

The Parameters tab contains two parameter lists:

• Input parameters—Specifies the parameters that receive values from sources that are external to the test or component.

• Output parameters—Specifies the parameters that pass values to sources that are external to the test or component.

You can edit an existing parameter by selecting it in the appropriate list and modifying its details.

You can add and delete input and output parameters for your test or component using the parameter control buttons:

Option

Description

Adds a parameter to the appropriate parameter list. Enter a name for the new parameter and select the parameter type. You can enter a description for the parameter, for example, the purpose of the parameter in the component. If you are defining an input parameter, enter a default value for the parameter in the Default Value column.

You define test or component parameters in the same way you define action parameters.

Removes the selected parameter from the test or component.

Defining Values for Input Parameters

When the test or component runs, QuickTest uses the default value for each defined input parameter if a specific value has not been defined for the parameter in either QuickTest or Quality Center.

When you run a test or business component from QuickTest, input parameter values for tests and components are taken from in the Input Parameters tab of the Run dialog box.

Using Test or Component Parameters

Once you have defined test or component parameters, you insert them in your test or component by specifying the test or component parameter name with the Parameter reserved object, in the format: Parameter("ParameterName").

Action Parameters in qtp scripting

2009-05-13T11:15:00.000-07:00

In QTP scripting there are mainly 3 types of variable that we use. They are:

Action Parameters.
Environment Variables.
VB Variables, which we declare in the script.

Action Parameters

Action parameters enable you to transfer values between actions and their nested actions in your test, from your test to a top-level action, or from a step in a top-level action back to the script or action that ran (called) your test. For example, you can output a value from a step in a nested action and store it in an output action parameter, and then use that value as input in a later step in the calling parent action.

You define the parameters that an action can receive and the output values that it can return in the Parameters tab of the Action Properties dialog box. You specify the actual values that are provided to these parameters and the locations in which the output values are stored in the Parameter Values tab in the Action Call Properties dialog box.

You can specify input parameters for an action so it can receive input values from elsewhere in the test. Input values for an action can be retrieved from the test (for a top-level action) or from the parameters of the action that calls it (for a nested action). You can also specify output parameters for an action, so that it can output values for use later in the test, or pass values back to the application that ran (called) the test.

Setting Action Parameters

You can specify input parameters for an action so that steps in the action can use values supplied from elsewhere in the test. Input values for an action parameter can be retrieved from the test (for a top-level action) or from the parameters of the action that calls it (for a nested action). You can specify output parameters for an action, so that it can return values for use later in the test. For each input or output action parameter, you define a name and a type. You can also specify a default value for each action input parameter, or you can use the default value that QuickTest provides for the parameter value type that you choose. The default value is saved with the action and is used by the action if a value is not defined for a parameter in the action call. You can define, modify, and delete input and output parameters in the Parameters tab of the Action Properties dialog box.

To add a new input or output action parameter:

Click the Add button next to the Input parameters or Output parameters lists to add a new parameter to the appropriate list. A row for the new parameter is added to the relevant list.

Click in the Name box and enter a name for the parameter.

Select the value type for the parameter in the Type box. You can select one of the following types:

String—A character string enclosed within a pair of quotation marks, for example, "New York". If you enter a value and do not include the quotation marks, QuickTest adds them automatically when the value is inserted in the script during the test run. The default value is an empty string.
Boolean—A true or false value. If you select a Boolean value type, you can click in the Default Value column and click the arrow to select a True or False value. The default value is True.
Date—A date string, for example, 3/2/2005. If you select a Date value type, you can click in the Default Value column and click the arrow to open a calendar from which you can select a date. The default value is today's date.
Number—Any positive or negative number. The default value is 0.
Password—An encrypted password value. If you select a Password value type, the password characters are masked when you enter the password in the Default Value field. The default value is an empty string.
Any—A variant value type, which accepts any of the above value types. Note that if you select the Any value type, you must specify the value in the format that is required in the location where you intend to use the value. For example, if you intend to use the value later as a string, you must enclose it in quotation marks. When you specify a value of Any type, QuickTest checks whether it is a number. If the value is not a number, QuickTest automatically encloses it in quotation marks. If you are editing an existing value, QuickTest automatically encloses it in quotation marks if the previous value had quotation marks. The default value is an empty string.

If you are defining an input action parameter, click in the Default Value box and enter a default value for the parameter or you can leave the default value provided by QuickTest for the parameter value type. The default value is required so that you can run the action without receiving parameter values from elsewhere in the test.

If you wish, click in the Description box, then enter a description of the parameter, for example, the purpose of the parameter in the action.

To modify an existing action parameter:

1. Select the parameter you want to modify from the Input parameters or Output parameters list.

2. Modify the values as necessary in the edit boxes of the parameter row.

To delete an existing action parameter:

1. Select the parameter you want to delete from the Input parameters or Output parameters list.

2. Click the Delete button . The parameter is removed from the list.

Limitations in object repository

2009-05-13T11:10:00.000-07:00

Limitations:

1. Mercury Interactive recommends that you keep the Object Repository under 1 MB and perform regular backups. If the size crosses more than 1MB loading of object repository takes lot of time .

2. The limitation on the number of Actions is 255. The reason is that each Action has a data table sheet. The Formula 1 control has a limitation of 255 sheets so the limitation is 255 Actions per test. You may be able to add additional Actions after reaching the 255 "limit", however those Actions will not be able to access a local data sheet.

Note: If you are calling reusable Actions, you may be able to have more than 255 Actions within the script. This can be accomplished if you are calling the same Action more than one time within the script. The data sheet for the Action will only be loaded once. This applies to "call to" Actions only.

Example:

In a new script, insert a "call to" a reusable Action. When the Action is added to the script, you will see the data sheet added to the data table. Insert another "call to" to the same Action. The data sheet will not be added again.

Points to be considered when addressing an automation project

2009-05-12T03:07:00.000-07:00

The following are some general considerations to be taken into account when initiating a project automation software.

The first step is to analyze the feasibility of the automation.

Consider the following:

* The limitation of resources,
* The budget,
* The schedule and;
* The knowledge available.

Therefore it is expected that not all combinations and permutations of use cases / test in an application can be tested, and therefore not all tests can be automated.

Will require a great effort from the team, set priorities for automation.

One way to do this task is to create an "index of automation."

If the project is to automate processes that were hitherto tested manually, the calculation should be done as follows: Number of test cases to automate viable dividing the total number of test cases.

The term "number of test cases to automate viable" is used because, while almost all the test cases can be automated, given the limitations set forth above, not all can be automated effectively. Therefore, it is very important to distinguish the cases that can be automated for those who are really practical to do so. (Here we should also add as an ingredient of the domestic policy issue in most situations influences and impacts throughout project).

The analysis of all potential test cases to be automated through the use of this list will help reduce the likely number and focus on those cases that are most viable to be automated.

After reaching this first step and the first result, we must consider whether the experience and resources of the organization will implement the process of automation.

After this stage, we must consider very carefully the criteria referred to the risks and complexity in the test cases, and from personal experience that in some situations are more difficult to establish automation, so the project leaders must carefully assess the balance between the development of the command to run the test automation against time and cost required to develop the functionality itself.

After reaching this stage and have received a number of cases candidates, the next step is to analyze the feasibility of automation, as if some functionality is in development stage there will not be stable enough in the flow or workflow to consider and therefore some of the commands built for the run of the test will generate errors or warnings.

Defect Report Template (Standard Format)

2009-05-12T03:02:00.000-07:00

Defect Report is probably the main deliverable for most software tester (test systems). A good report faults, represents a very important and understandable information. In contrast, a weak Defect Report, it generates extra work for others. Most times, a report of weak defects is returned with comments like: not reproducible, it requires more information it is not understandable, poorly tested, and so on.

This leads to work as a result again on the same defect, and therefore reduces the efficiency of developers and testers. Defect Report is not only used by programmers, but also for managers, executives, project team and support staff, ie that such documentation is "exploited" for different user roles within an organization to different purposes.

The purpose of a report defects in any organization is changed, because it is used for:

Alerting systems programmers about the defect, giving them enough information to find the root cause and thus solve the problem originates.

Provide technical information to those responsible for drafting the "troubleshooting" or reports of limitations will then for example to support users.

Provide starting points for the next version of the system

Incorporate test cases for regression testing in the next release

A good Defect Report should be simple, understandable, reproducible, legible, and without prejudice.

The basic structure of the template should consist of the following sections:

Title
Product
Component
Type of Defects
Priority
Severity
Environment
Sequence of steps
Attachments
Comments

1. Title

Brief description of the defect, if possible in one line.

2. Product

In general, the defect-tracking systems manage more than one system (with their corresponding modules), which is why it is important to specify (in case the application fails to do so) to the product or version is concerned.

3. Component

This point is related to the previous point where you specify in more detail about which component should be acting to correct it is, for example, that system module fault has occurred. In this way, this information will assist the manager in the allocation of its correction.

4. Type of Defects

The type of defect could be: aesthetics, navigation, functional, not functional, regression, etc.. In this way, this classification may be helping to further analysis of how they are distributed defects in the system.

5. Priority

This factor is the impact that defects in the business, ie how much impact their effect on the operation of the business. Usually, this factor does not edit or modify the tester but the person who is responsible for development, or functional test, or project.

6. Severity

Is the impact of the defect.

7. Environment

Information related to the environment on which it must be running the test.

8. Sequence of steps

Is the sequence of steps, points and interim results to be followed to the effect that anyone can just reading, to reproduce the fault.

9. Attachments

Can be offered to programmers, eg screenshots (screen capture) files generated by the proven option, logs, etc..

10. Comments

Any information that can supplement the understanding of the programmer fault.

What is the role of a tester?

2009-05-11T09:12:00.000-07:00

The tester is an expert in the implementation of the testing and reporting of incidents. Has basic knowledge in IT, testing, use testing tools, and understanding of the object under test. Its tasks are:

Review test plans and test cases

Use of monitoring and testing tools (eg tools for performance)

Implementation of logging and testing, evaluating results and documenting the results and the deviations

The tester is an expert in executing tests and incident reporting (IT basics, testing basics, applying the test tools, understanding of the test object). Tester Typical tasks may include:

Reviewing test plans and test cases

Using test tools and test monitoring tools (for example tools for performance measurement)

Executing and logging test, evaluating the results, and documenting the results and the Deviations

Types of Software Testing

2009-05-11T08:00:00.000-07:00

Black box:

Not based on knowledge of internal design or code, determines the functionality of the system.

White box :

It is based on the internal logic of the application and the code. Makes a coverage of code statements, branches, paths and conditions.

Unit :

It is the smallest scale of the test is based on the functionality of the program modules, functions, procedures, modules, classes, etc.. In some systems also are checked and tested the drivers and architectural design.

Incremental Integration:

When new features are entered into the test system is based on functionality, the unit with other modules and integration with the whole program.

Integration :

It is based on the evidence of connections and communications between different modules. It is essential cliente_servidor system or network.

Functional :

Does the black box functional testing requirements of the application and is usually done by the programmer, however, the functional test is done by testers.

System :

It is a black box test including all components of the system from the hardware documentation.

From end to end:

It is similar to the test system but this involves interaction with other hardware, databases and networks.

Health:

Determines whether the new version of software is well done and if you need a new effort in testing software. For example the new version of a program meets almost all requirements
but destroys the database to read, so it is said that this software is not in a healthy condition.

Regression :

It's a new review of the evidence after he has suffered hardship or a change of time or was the change in the environment in which it operates. Currently
there automated tools that make this type of evidence does not bear too long.

Acceptance :

It is the final test based on the specifications of the user or based on the use of the program by the end user after a period of time.

Load:

Based on applications under heavy loads, often used on websites and servers with large data sets where there are points at which degradation of the system.

Performance or response:

It is one of the final tests and is used to define the requirements and software quality, based on load testing and stress. Includes interviews with the user and programmer.

Stress:

It is a load test and performance or response (performance) based on the functionality of the system under heavy loads, a large number of repetitions, managing large data and too many questions to large databases.

Installation and removal:

Determines the efficiency of the processes that the applications installed and uninstalled the program.

Recovery:

Is the test that evaluates how well the system recovers after locking, hardware failures or other catastrophic problems.

Safety:

Assesses how well the system protects against access, internal or external, unauthorized, this test requires sophisticated techniques and tools.

Compatibility:

Evaluates the performance of the software on different hardware, operating systems, networks.

Exploration:

It is an informal test of the software that is not based on any plan or test case and often the testers of the program to learn to explore all possible applications.

Listing:

It is similar to the proof of exploration but the testers must have sufficient understanding of how the program works before you start this test. Includes meeting with analysts and programmers.

User:

Determines if the user performs satisfactorily in the program.

For comparison:

This test compares the pros and cons of the program with the programs set up with the competition.

Alpha :

Is the test when the application is close to delivery to the user. Generally small changes are made in the design of interfaces. This test is done by users.

Beta :

It is the search for defects in the program. It is usually made by users.

Mutation :

This test is based on the introduction of codes outside the program (defects) to review whether these defects can be detected. Requires high availability of computing resources.

Common mistakes of project management software

2009-05-11T07:57:00.000-07:00

The seven most common mistakes of project management software

Trying to define all requirements in advance
Ignore the three key factors: scope, time and resources
Trying to define all the development tasks ahead
Setting unrealistic expectations of the customer
Continue the activities instead of watching
Do not plan to update the base
Waiting months to get feedback

Two of every three software projects are delivered late, over budget or without all of the requirements requested (result of the study by the Standish Group)

Software projects must respond to changes arising from new technologies, which are increasingly demanding requirements in terms of time, functionality, scalability, all this due to the rapidly changing market and changing business needs.

In the past ten years, a little less in our country (Argentina), has seen an increase in agile methodologies for such projects, which are applied by other management techniques that foster close communication with the customer and less ceremonious than traditional methods.

SOFTWARE TESTING

2009-05-11T07:42:00.000-07:00

The objective of software testing is to ensure that the software meets the specifications required and eliminate any defects that may have. At first the majority of companies in development stage had a very informal test, currently the software testing has become one of the most critical stages of the life cycle of software development and this has caused the origin of various methodologies.

Currently the software testing becomes more complicated because it must cope with a large number of development methodologies, programming languages, operating systems, hardware etc..

This is why testing must rely on general methodologies to review the most fundamental aspects to consider any testing process. Because of this complexity, there are now a large amount of software designed exclusively for the stage of testing, including managing the process of software testing, administration and troubleshooting, the administration of the test cases, test automation and so on.

After completing the stages of analysis, design and development phase begins testing at this stage it is recommended that the software is kept in an environment isolated or separated from the development environment or production, it is best to prepare an environment tests as similar to existing production environments to ensure their proper functioning at that future stage, should consider purchasing a specialized test equipment software tester or test analyst with experience, these people have training that enables them to detect a large number of errors in minimum time and a specific methodology that allows them to do the job correctly.

Some companies use more informal for future users of the system testers which can bring a number of problems due to poor experience that can have users in error detection, as well as important evidence obviates the stress test or "stress testing", is also sidelined the modular unit tests or tests, they should ensure that each module of the system to work correctly independently, another well-known bug in software companies is the use of the same developers as analysts of evidence, it is very difficult to prove objectively whether a software we developed ourselves, a technical analyst or a test program began with preconceived idea that his son works seamlessly and unconsciously avoid more extensive testing whereas they could be silly or unnecessary, the good news is that gradually these ideas are being discarded and concepts to be lining up a software testing professional.

Merging of two object repositories

2009-05-11T01:41:00.000-07:00

General:

The Object Repository File Merge Utility allows users to merge object repository files into a single file. This utility is intended for an advanced user that builds powerful tests.

The Merge Utility allows you to merge the content of one Object Repository to another one thus giving you the flexibility and the power in controlling the content of the Object Repository and the ability to dynamically change this content.

Conflicts:

The implementation of the merge algorithm is quite simple when the object repository files have different objects in them, or if all objects had only exact replicas in other files. Due to the nature of the operation it is often not the case. For example, if we try to merge two object repositories from tests that were recorded at different time points, between which some test objects properties have changed (e.g. whether a button is enabled) then the same object exists in the two repositories with different properties. We call this a description conflict as the two objects have the same name, but different descriptive properties. It can also be that the user has decided to modify the automatically assigned logical name of an object (for example, in order to create a shorter name) in one repository but not in the other. In this case, two objects will exist with different logical names, but with the same descriptive properties. We call this a name conflict.

Resolving Conflicts:

It is not trivial to identify and handle conflicting objects. The user might want to merge two objects that were not initially the same, or decide to keep two objects that for the inexperienced eye would seem identical. For example, recording on web browsers would likely generate identical logical names for browsers that have nothing in common. It is also likely that if the text on a button has changed, new tests would record a new logical name for it, even though the object behavior has not changed. It is therefore possible to either keep the two objects (and their subtrees) separated, to assume that the two objects are actually the same object, or to ignore one of the conflicting object. We will discuss these choices later in detail.

Note: The Merge Utility works only on machines where QTP8.0 is installed.

Merge Object Repositories Utility

Main Window:

This utility is designed to supply simple access to the functionality implemented by the ObjectRepositoryMgr COM component. As the operation is not trivial, the UI has many options to select, so we will discuss the different options in detail.

Per Action/Shared Object Repository

2009-05-11T01:34:00.000-07:00

Setting the Shared /per action Object Repository option

To set only one test to use the Shared Object Repository option:

1. Click the "New" button or go to File -> New to open a new test.

2. Go to Test -> Settings.

3. Select the Resources tab.

4. In the Object repository type box, select one of the options:

Select "Per-action" to set the Object Repository mode for your test to the Object Repository per action mode.

Below are some of the factors based on which Per Action option is selected

Whenever there are no common objects across transactions

Ease of building object repository.

Loading of per Action object repository takes less time as the size is less

Select "Shared" to set the Object Repository mode for your test to the Shared Object Repository mode.

Below are some of the factors based on which Shared Action option is selected

Whenever there are common objects across transactions

Maintenance of object repository is very easy

Whenever size of object repository is 1MB

5. If you selected Shared in step 4, specify the Shared Object Repository file you want to use as the test's Object Repository file. To specify a file, enter the Object Repository file name or click the "Browse" button and select a resource file (*.tsr) from the Open dialog box. To create a new Shared Object Repository file, enter a new file name in the Shared box.

Note: These steps need to be done in a new script. Once you have modified the script, you will not be able to change the option.

To set all new scripts to use a Shared Object Repository:

For Quick Test Professional 6.5 and above

Click the New button or go to File -> New to open a new test.

Go to Test -> Settings.

Select the Resources tab.

Select the Shared option for the "Object-repository type".

Specify the Shared Object Repository file you want to use as the test's Object Repository file. To specify a file, enter the Object Repository file name or click the ellipse button <...> and select a resource file (*.tsr) from the Open dialog box. To create a new Shared Object Repository file, enter a new file name and path in the Shared box.

Click the "Set as Default" button.

Click and .

QTP - Splitting Actions, Re-usable Actions, Internal/External Actions

2009-05-09T01:55:00.000-07:00

Actions help divide your test into logical units, specific activities that you perform in your application.

A test is made up of calls to actions. When you create a new test, it contains a call to a single action or create tests that call multiple actions by inserting calls to them, to make the design more modular and efficient tests.

There are three kinds of actions:

• reusable action—an action that can be called multiple times by the test with which is stored in 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. They can be modified only in the test with which they are stored.

• Non-resuable-actions —an action that can be called only in the test with which it is stored, and can be called only once.

Quicktest - Script Startup

2009-05-09T01:51:00.000-07:00

Script Startup

• Check for the required add-ins for an application.

• Include action template for every test containing script id, Action name, Action Description, Recovery scenario used etc.

• Every action, scenario must be specified with an appropriate name.

• Check for mandatory input fields for all iterations in the datasheets that are being imported.

Example:

The Resources tab of the Test Settings dialog box can be used to associate specific files with the test, such as Data Table files.

The option area Other location instructs Quick Test to use data stored in the specified Data Table location. The Data Table can be any Microsoft Excel (.xls) file.

• Check for the “Data table iterations” under the test settings for which the test has to be run.

QTP - Action Template

2009-05-09T01:48:00.000-07:00

Creating an Action Template

If you want to include one or more statements in every new action in your test, you can create an action template. For example, if you always enter your name as the author of an action, you can add this comment line to your action template. An action template applies only to actions created on your computer.

To create an action template:

1. Create a text file containing the comments, function calls, and other statements that you want to include in your action template. The text file must be in the structure and format used in the Expert View.

2. Save the text file as ActionTemplate.mst in your \dat folder. All new actions you create contain the script lines from the action template.

Only the file name ActionTemplate.mst is recognized as an action template.

Quicktest - Iterations using rows

2009-05-09T01:34:00.000-07:00

The Run tab includes the following options:

Option	Description
Run one iteration only	Runs the called action only once, using the row in the action's data sheet that corresponds to the current global iteration number. If the action's data sheet contains fewer rows than the global sheet, the last row of the action's data sheet is used for each subsequent test iteration. For example, suppose an action's data sheet has two rows and the global sheet has four rows. If you choose to run one iteration only for the action and you choose to run iterations on all rows of the global data sheet, then during each iteration of the test, this action will run only one iteration. The data that the action parameters use during each repetition of the test are based on the iteration number for the test. During the first iteration of the test, Data Table parameters in the action take data from the first row of the action's data sheet. In the second iteration of the test, Data Table parameters in the action take data from the second row of the action's data sheet. In the third and subsequent iterations of the test, the Data Table parameters in the action continue to take data from the second i.e. the last row of the action's data sheet.
Run on all rows	Runs the called action with the number of iterations according to the number of rows in the action's Data Table.
Run from row __ to row __	Runs the called action with the number of iterations according to the specified row range.

The Run tab of the Action Call Properties dialog box applies to individual action calls and refers to the rows in the action's data sheet.

Quicktest - Actions Settings

2009-05-09T01:30:00.000-07:00

Actions Settings

You can use the Run tab of the Action Call Properties dialog box to instruct QuickTest to run only one iteration on the called action, to run iterations on all rows in the Data Table, or to run iterations only for certain rows in the Data Table.

QTP - Importing and Exporting Datasheets

2009-05-02T07:31:00.000-07:00

Description

Importing and Exporting of Datasheets are used for reading, writing and manipulating the data in an excel sheet.

Importing Datasheet:

Description

Imports a sheet of a specified file to a specified sheet in the run-time Data Table. The data in the imported sheet replaces the data in the destination sheet (see SheetDest argument).

Note: All the fields in the imported sheets should match with the data used in the script.
There are two functions for Importing, Importing the whole excel file and Importing the sheets in the file.

Function for Importing the whole Excel file:

Imports the file into the script with all the sheets which are there in the excel file.

Note: Sheets in the excel file should match with the Actions in the script to use the data efficiently, since action name and corresponding sheet name should be same.

Syntax:

Import “filenamewithpath”

Function for Importing the sheets from the excel file:

Imports the specified sheet into the script.

Syntax:

Importsheet “filenamewithpath”,”sourcesheetname”,
”destinationsheetname”

Exporting Datasheet:

Description

Exports a specified sheet of the run-time Data Table to the specified file.

If the specified file does not exist, a new file is created and the specified sheet is saved.

If the current file exists, but the file does not contain a sheet with the specified sheet name, the sheet is inserted as the last sheet of the file.

If the current file exists and the file contains the specified sheet, the exported sheet overwrites the existing sheet.

Same as Importing, There are two functions for Exporting, Exporting the whole excel file and Exporting the sheets in the file.

Function for Exporting the whole Excel file:

Exports the file into the script with all the sheets which are there in the excel file.

Syntax:

Export “filenamewithpath”

Function for Exporting the sheets from the excel file:

Exports the specified sheet into the script.

Syntax:

Exportsheet “filenamewithpath”,”sourcesheetname”,
”destinationsheetname”

QTP - Parameterizing using Data driven Wizard

2009-05-02T07:20:00.000-07:00

Parameterizing using Data driven Wizard

Description

The Data Driver enables you to quickly parameterize several (or all) property values for test objects, checkpoints, and/or method arguments containing the same constant value within a given action.

You can choose to replace all occurrences of a selected constant value with a parameter, in the same way that you can use a Find and Replace All operation instead of a step-by-step Find and Replace process. QuickTest can also show you each occurrence of the constant so that you can decide whether or not to parameterize the value.

If any property of an object is taken, that property can be parameterized using Data driven Wizard,

Different steps for parameterization using Data driven Wizard is as follows:

Go to tool bar option Tools and select Data Driver option

We will get a list of all the properties of all the objects which can be parameterized (i.e. for all the objects where a value for a property is given in the script)

For example consider script for entering Login name which is as follows

Dialog("Login").WinEdit("Agent Name:").Set "name"

The Set property of WinEdit Object appears in the list of Datadriver with “name” as Value representing the Set property of “Agent Name” Editbox, which is as given below:

Select a value which should be parameterized and click on “Parameterize” button.

There will be two options to be selected as given below:

Step-by-step Parameterization: Enables you to view the current values of each step containing the selected value. For each step, you can choose whether or not to parameterize the value, and if so, which parameterization options you want to use, the Next button is enabled when you select this option, this will enable us to select an other instance of the constant selected and parameterize that instant, it will continue the same process till all the instances of the given value are done.

Parameterize all: Enables you to parameterize all occurrences of the selected value throughout the action.

When you select this option the Parameter details area is enabled. The Finish button is enabled when you select this option.

Here Parameter tab can be selected using the button given at the “Parameter” radio button, and in the next screen select the datatable Field from where the property for which the value belongs is parametererized, click on “Finish” button thus all the instances of the value selected for parameterization will be parameterized.

QTP - Organizing Data Sheets for Global & Local variables

2009-05-02T07:18:00.000-07:00

Organizing Data Sheets for Global & Local variables

Description

There are two types of sheets in any QTP Script, they are

Globalsheet
Localsheet

Globalsheet: Globalsheet in any script is unique, Globalsheet is used in order to store values in the sheet and the values stored in Globalsheet can be used in all the actions.

For storing a value in the global sheet we use the following function:

Datatable.Value(“Fieldname”,”Global”) = Value

For using the values from the global sheet we use the following function:

Value = Datatable.Value(“Fieldname”,”Global”)

Localsheet: Each and every action in the script will have its own Localsheet, name of the Localsheet of a particular action is same as the action name.

For using the data from the Local sheet we use following function:

Datatable.Value(“Fieldname”,dtlocalsheet)
Or
Datatable.Value(“Fieldname”,”Sheetname”)

Organization of Global and Local sheets with the actions used in the script are shown below:

QTP - Datatable Object and related Functions

2009-05-02T07:16:00.000-07:00

In QTP scripting there are many objects that are used, One of the Objects used in QTP scripting is DataTable Object.

Datatable Object and related Functions:

Description

Basic use of Datatable object is to create an object for adding, deleting, updating data of an excel sheet used.

Main functions of the datatable object:

• Importsheet : This function is used to Import sheet into the script, so that all the data in the imported sheet can be used in the script.

Syntax:

Datatable.Importsheet(“nameofExcelfilewithpath”,
“nameofthesourcesheet”, “nameofthedestinationsheet”)

• Exportsheet : This function is used to Export sheet from the script, all the data including output values are stored in the default sheet for the action, this sheet is exported and stored in a specified location using this function.

Syntax:

Datatable.Exportsheet(“nameofExcelfilewithpath”,
“Nameofthesheet”)

• Addsheet : Used for adding a sheet into the script file.

• GetRowCount: This function is used to get the no of rows in a particular sheet.

Syntax:

Datatable.AddSheet(“Sheetname”).GetRowCount

• GetCurrentRow: This function is used to get the current row of a particular sheet.

When an action is run by using run setting as “run on all rows”, that action will run as many times as the number of rows in the excel sheet of the action, in order to find the row for which action is running currently we use GetCurrentRow function.

Syntax:

Datatable.GetSheet(“Sheetname”).GetCurrentRow

Objects in QTP Frame work

2009-04-27T01:20:00.000-07:00

Objects

Objects are the things which contain different properties and methods.

For Example: Window is said to be an object which consists of properties such as Exist, GetROProperty and methods such as ChildObjects, Activate, maximize, minimize etc.

Property:

Property describes about the object defined, each object has different properties, which is necessary to describe the object, which differentiates the given object with other objects.

For example: If we take a window object, we first have to define to which class it belongs to which is one of the property, it belongs to a window class. Exist is a property which is common to many objects which returns true if that object exists.

Methods:

Methods are functions, which are used for changing the properties of the object that is in order to manipulate with the object properties we use.

For example: If we take a window object, Activate is a method used to activate the window object, thus by using Activate method Activate property of the present window object is set to true, thus the window object will be activated if not in activated mode.

Sample for Object hierarchy:

(click to enlarge)

In the above sample of code, there are two main Objects, one is Dialog and the other is Window object. This objects contain child objects, For Dialog object which is named as “Login” has WinEdit object with name as “Agent Name:” as childobject, here Set is the method used to set a text into the WinEdit object

QTP Setting related to the Application Used

2009-04-27T01:09:00.000-07:00

Setting related to the Application Used:

The different kind of Applications that can be tested using QTP are windows applications,web based(java and .Net),SAP,Oracle etc.Apart from the windows applications using MFC and simple web applications(which can be run with default add-ins), rest all applications require a special Add-in to be purchased to do the testing.Each

Add-in which is bought and installed, results in a new tab in all the setting dialog boxes , using which various setting options can be chosen.It purely depends on the type of application , how to choose a particular setting option.

Example of a SAP Add-in :

The Add-in manager dialog with SAP add-in

Record and Run Settings with a SAP Add-in

Step Generator

2009-04-24T00:16:00.000-07:00

If the user is familiar with VBScript, the user can add and update statements and enhance the tests and components with programming. After the test or an Action is recorded, its power and flexibility can be increased by adding recordable and non-recordable VBScript statements as required for tasks like Check Points,Datatables etc.,.These additional steps can be added either manually or using Insert>Step >Step Generator .whenever a step is added to a script, then any Syntax errors of the step can be Identified in its Keyword view.

The Step Generator enables you to add steps quickly and easily, by selecting from a range of context-sensitive options and entering the required values.The generated step gets added at the position of cursor in the expert view.

The Step Generator enables you to add steps quickly and easily, by selecting from a range of context-sensitive options and entering the required values. In the Step Generator dialog box you can define steps that use:

• test object methods and properties

• utility object methods and properties

• calls to library functions, VBScript functions, and internal script functions

Expert View

2009-04-23T23:55:00.000-07:00

While recording Tests in QTP, there are 3 important views that enable us to understand clearly, the various representations of the Script. They are

a. Expert View

b. Keyword View: Hierarchical Representation of Actions

c. Active Screen View: Pictorial view of the currently active Screen.

In the Expert View, QTP displays each operation performed on the application in the form of a script. The script is comprised of VBScript statements and the view is a script editor with many script editing capabilities. For each object and method in an Expert View statement, a corresponding row exists in the Keyword View and a corresponding Active Screen in the Active Screen view, which enables easy traceability.

Fig: Active Screen Component corresponding to Expert View Statement

Fig: Keyword view and Active Screen view corresponding to one expert view statement

Object Repository

2009-04-23T23:47:00.000-07:00

When a test is recorded, QTPadds each object on which an operation is performed, to the Tools>object repository. Objects can be added to the repository while editing the tests too.While recording, Objects are added to the repository in either of the two ways:

a. Object Repository per Action

b. Shared Object Repository.

The settings can be changed by going to

Test>Settings>Resources>Object Repository Type

In the Per-Action mode, objects are identified and separated on the basis of each action and the corresponding object repository for the test is created in the test folder.In the Shared mode, the user may choose a location to save the shared object repository files for all the tests.

All the Objects recorded during a test,and their properties can be seen and manipulated in the Tools>Object Repository.There are provisions in this Object Repository Dialog box to add new objects,spy objects, find and replace property values etc.

The First Section of Object Repository Dialog Box contains provisions to

a. Add Objects : A Button to add new objects to the repository.

b. Highlight: To highlight the object selected in the repository, when the application is open.

c. Object Spy: To Spy any Object, to see its Properties.

d. Export: To Export any objects to an outside location.

The second section of the dialog box contains provision to Find, Replace, Add, and Remove the properties of an object in the Repository also set any default values for the properties.

Active Screen Capture Level

2009-04-22T21:38:00.000-07:00

One of the most useful fetaures of QTPis the various views it provides, out of which Active view is the most unique.The selection of the appropriate Active Screen Capture level influences the storage space, properties stored and the view of the Active screen. The selection can be made by going to Tools>Options>Active Screen.

The Active screen settings can also set at the Test>Record and Run Settings.

The active screen capture level can be set to any of the 4 levels i.e. Complete, Partial, Minimum and None.

Record and Run Settings

2009-04-22T21:28:00.001-07:00

After Setting the Test Settings at Test>Settings, the next important settings for actually recording the application and running it for Testing are to be set at the Test>Record and Run Settings. This dialog box opens automatically, when recording a test for the first time. The details of which application to record are set in this dialog box.

QTP Test Settings

2009-04-22T21:17:00.000-07:00

Before Running or Recording any test on QTP, the QTP Test settings need to be set as per the requirements of the Test. Setting these Test Settings before starting a Test plays a crucial part in the behavior of the test.

These can be found at the path Test>Settings. A dialog box pops up, in which various tabs are present which allow one to set

• Properties of the test like Add-Ins used
• Run time Preferences
• Resources like files, data tables, and repository to be used.
• Parameters required in the Test.
• Environment variables used
• Web navigation
• Recovery Scenarios

Data Sheet Naming and Parameter Naming Conventions

2009-04-18T12:06:00.000-07:00

DataSheet Naming and Parameter Naming Conventions:

Every QTPTest Script contains 2 types of sheets.

1. Global data sheet
2. Local data sheets

The Global data sheet, which is a common sheet for all the actions of the script, is named by default as dt_globalsheet. This can be renamed as Global for all the Scripts for consistency.

Typically, Each Action in the Script contains one data sheet, which is local to the Action. This is by default, named after the Action to which it belongs. Therefore the name of the datasheet follows directly the name of the Action, which when named following its naming conventions, can be used efficiently for the data sheet too.

Parameter Naming:

Various Types of Parameters used in QTPare:

1) Test Parameters

a) Test Input Parameters: These should be named as IN_(relevant variable name). ‘In’ denoting that it’s an input parameter for the Test in whole. The name following IN should be a relevant name for the variable, denoting the purpose of its use. This should also comply with the standard variable naming conventions.
Example: IN_bFlag, IN_iIncrement etc.,

b) Test Output Parameters: On the similar lines of Input Parameters, these should be named as OUT_(relevant variable name). OUT representing that it’s an output parameter.
Example: OUT_sStatus.

2) Action Parameters

a) Action Input Parameters: These are local to Action of a Test. These can be named as ACTIN_(variable name). ACTIN denoting that it’s an Action Input Parameter.
Example: ACTIN_iResult

b) Action Output Parameters: These could be named as ACTOUT_(var name).
Example: ACTOUT_bFlag

3) Environment Variables:

Environment variables are either built-in or User defined. Built-in variables cannot be declared named by the user, so their naming convention is not discussed.

User Defined Environment Variables are either Internal or External.
Internal Variables: ENV_INT_(variable name)
External Variables: ENV_EXT_(Variable name)

Function Naming Conventions:

Functions should be named as Func_(name). This can provide clarity and difference between a Reusable Action and a Function that can be used within Actions.

Example: Func_Save , Func_Add

Variables and Constants

2009-03-31T07:07:00.000-07:00

QTPScripts are in VB Script. Therefore, the naming conventions for variables can be followed alike VB Script Naming Conventions.

General Conventions followed in VBScript are:

Data Type Prefixes:

By using data type prefixes, your variables always indicate what they are designed for. I'm using just six prefixes:

Prefix	Data Types	Example
b	Boolean (true or false)	bChecked = True
d	Date/time	dStartTime = Now
i	All numeric data types (Byte, Integer, Currency, Long, Single, Double)	iTax = iPrice * 0.076
o	Objects	Set oFile = Nothing
s	Strings	sTitle = "Welcome!"
u	User interface elements	uPara.style.display = "block"

Constants Prefix:

Usually there are only a handful of constants in any scripts. Indicating the data type therefore is less important for constants. Prefix letter c for all constants can be used.

e.g. Const cTitle = "Welcome!"

UDocument.title = cTitle

Script and Action Naming Conventions

2009-03-31T06:51:00.000-07:00

Similar to the Test case naming, Script naming should be done consistently with clarity and traceability. Typically each Test Script is prepared corresponding to each Test Case. Every Test Case contains one or more Conditions. Each Condition can be represented by an action in the script.

Action Naming:

Each Test Script can contain one or more Actions, with one or more actions representing a test Condition.

Actions can be named in 2 ways:

1. Functionality of the Action
2. Hierarchy of the Action in the Test Script.

1. Functionality of the Action:

Typically Actions are segregated by their functionality in the Test Script. Therefore it would be easier to understand the Action if the name of the action represents the Functionality.

For E.g.: An Action written or recorded for logging the user should be named as Login or Authentication for easy understandability.

An Action for booking tickets should be named as Book_Tickets

An Action for exiting the application named as Exit.

This also adds a huge advantage when the Actions are made reusable. Reusable Actions can be used between various scripts. When an Action is to be made reusable the action should be named as REUSE_(Action name).

Example: REUSE_Login.

2. Hierarchy of the Action in the Script:

Since Actions are a part of the Test Script, for purpose of Clarity and tracking, Actions can be named as per Hierarchy.

For e.g.: Test Case Name = TC_01

QTPTest Script Name = QTS_01

Name of 1st action in the Script = QTS_01_01

Similarly Name of 9th Action in the Script = QTS_01_09

Test Case Naming Conventions

2009-03-31T05:38:00.000-07:00

The Conventions for Naming for test cases, Scripts and Actions vary from Project to Project depending upon the Client.

Test cases should be named in a manner that enables easy identification of the corresponding Use case (or the Scenario) for which the Test Case is written. The Onlooker should be able to trace the test case back to the use cane name or Scenario name by the name of the Test Case. Consistency should be maintained in following the hierarchy of naming.

Test Case

Use Case Or Scenario

For example:

Example 1:

Considering that Each Use case is associated with one Test case. If the name of the Use Case were UC_001 then the Test case name would be TC_001.

Example 2:

In the Unilever Automation Project, SAP transactions are divided into different modules, in those modules different transactions are grouped together as a scenario, so for writing the test case for a particular scenario naming convention used is module name followed by scenario name.

For Module IMWM, if S014_01 is the scenario name, so name of the test case for the S014_01 scenario was given as IMWM_S014_01.

Conditions for Add-ins

2009-03-27T23:13:00.000-07:00

Java Add-In

When testing Java applets in a Web browser, you must load the Web add-in as well as the Java Add-in, and use the Web tab of the Record and Run Settings Dialog box to specify your record and run preferences. To test Java applets or applications running on Netscape 4.x’s built-in JVM (not Java Plug-ins), confirm that the Netscape 4.x browser is already installed before installing the Quick Test Professional Java Add-in. When testing Java applets in a Web browser web Add-in as well as java add-in must be loaded .To create a checkpoint, parameterize a step, or to add a method from individual java applets, the Java Add-in must be loaded.

.Net Add-In

The .Net add-in is required to support objects developed in .Net .In some cases, even though the application has been developed using .Net, when the page is sent to the browser, it is a plain HTML page. Quick Test Professional can recognize HTML controls like edit fields, buttons etc. without the .Net add-in. However, if a Web application contains complex controls like ActiveX or other controls developed in .Net like ASP.Net server controls, it is required to use the .Net add-in to achieve object recognition.

Sap Add-In

The Sap add-in is required for all SAP applications. In SAP application Grid Tables, Status Bar messages, Labels can be identified only if SAP Add-in is installed.

QTP Frame-work: Add-Ins

2009-03-27T23:09:00.000-07:00

Types of Add-Ins

QTP version

Add-ins

8.2

Java add-in 6.5

Oracle add-in 6.5

Siebel add-in 8.0

Terminal Emulator add-in 8.0

. Net add-in 8.2

Default Add-Ins: Active X Controls, Web &Visual Basic

8.0

. Net add-in 6.5.1

Sap add-in 6.5.1

Java add-in 6.5

PeopleSoft add-in 6.5

Oracle add-in 6.5

Terminal Emulator add-in 6.5

Default Add-Ins: Active X Controls, Web &Visual Basic

6.5

. Net

Web

Java

XML

Default Add-Ins: Active X controls, Multimedia, Visual Basic, Web

Note:

Quick Test Professional Siebel add-in 6.5 and Web services add-in 6.0 cannot be used with Quick Test 8.0.

The add-ins for Quick Test Professional 6.0 cannot be used with Quick Test Professional 6.5. If you are using Quick Test Professional 6.5, you will need to get the 6.5 version of your add-in.

Versions of QTP - QTP 8.0

2009-03-27T22:28:00.000-07:00

System Requirements

To successfully install and run QTP 8.0, you need the following minimum system requirements:

Computer/Processor:	IBM-PC or compatible with a Pentium II 266 MHz microprocessor (366 MHz recommended).
Operating System:	Windows 2000-Service Pack 3 or Service Pack 4, Windows XP-Service Pack 1, or Windows 2003 Server.
Memory:	128 MB of RAM (256 MB recommended).
Free Hard Disk Space:	250 MB of free disk space for application files and folders, and an additional 120 MB of free disk space on the system disk (the disk on which the operating system is installed). After Quick Test Professional is installed, it is recommended to have at least 150 MB free disk space on the system disk for the operating system and Quick Test Professional to run correctly.
Browser:	Microsoft Internet Explorer 5.5 Service Pack 2-6.0.

Supported Add-ins

The following external QuickTest 6.5.x add-ins are supported for use with QuickTest Professional 8.0:

Java Add-in 6.5
Oracle Add-in 6.5
PeopleSoft Add-in 6.5
Terminal Emulator Add-in 6.5
.NET Add-in 6.5.1
• SAP solutions Add-in 6.5.1

Note: Siebel Add-in 6.5, the .NET Add-in 6.5, the Add-in for SAP solutions 6.5, or any 6.0 add-ins,cannot be used with QuickTest Professional 8.0.1

Supported Environments and Programs

QuickTest Professional 8.0 supports creating, recording, and running tests or components using the environments and programs described below.

Standard Windows Applications

Win32 API
MFC

Visual Basic Applications

Visual Basic 6.0

Note: Visual Basic .NET applications are supported by the QuickTest Professional .NET Add-in.

Browsers

Microsoft Internet Explorer 5.5 Service Pack 2-6.0 (required)
Netscape 6.1, Netscape 6.22, Netscape 6.23, Netscape 7.02, and Netscape 7.1 (optional)
AOL 8.0 and 9.0 (optional)

ActiveX Grid Controls

In addition to basic support of ActiveX properties and methods, QuickTest Professional supports context-sensitive recording and verification on the following ActiveX Grid controls:

Name	ProgId
FarPoint Spreadsheet 2.5	FPSpread.Spread.1
FarPoint Spreadsheet 3.0	FPSpread.Spread.2
FarPoint Spreadsheet 3.5	FPSpread.Spread.3
FarPoint Spreadsheet 6.0	FPSpread.Spread.4
FarPoint Spreadsheet 3.0 (OLEDB)	FPSpreadADO.fpSpread.2
FarPoint Spreadsheet 3.5 (OLEDB)	FPSpreadADO.fpSpread.3
FarPoint Spreadsheet 6 (OLEDB)	FPSpreadADO.fpSpread.4
Microsoft Grid 1.0	MSGrid.Grid
Microsoft DataBound Grid 5.0	MSDBGrid.DBGrid
Microsoft Flex Grid 6.0	MSFlexGridLib.MSFlexGrid.1
Sheridan Data Grid 2.0	SSDataWidgets.SSDBGridCtrlApt.1
Sheridan Data Grid 3.1	SSDataWidgets.SSDBGridCtrlApt.3
Apex True DataBound Grid 5.0	TrueDBGrid50.TDBGrid
Apex True DataBound Grid 6.0	TrueDBGrid60.TDBGrid
Apex True OLE DB Grid 6.0	TrueOleDBGrid60.TDBGrid

ActiveX Calendar Controls

In addition to built-in support for ActiveX properties and methods, QuickTest Professional supports context-sensitive recording and verification on the following ActiveX Calendar controls:

Name	ProgId
Microsoft Date and Time Picker Control 6.0 (SP4)	MSComCtl2.DTPicker.2
Microsoft MonthView Control 6.0 (SP4)	MSComCtl2.MonthView.2

Microsoft Excel

When using Microsoft Excel files with QuickTest Professional 8.0(for example, to import or export data to or from the Data Table), you can work with Microsoft Excel 2000, 2002, 2003, and XP.

Microsoft Query

When using Microsoft Query with QuickTest Professional 8.0 (for example, for Database checkpoints), you can work with Microsoft Query 2000, 2002, 2003, and XP.

Additional Environments

QuickTest Professional add-ins support other environments such as Java, .NET Windows and Web Forms, SAP Solutions, Oracle, Siebel, PeopleSoft, Web Services, and terminal emulator applications. For more information on QuickTest Professional add-ins, contact your sales representative or Mercury Interactive Customer Support.

Versions of QTP - QTP 6.5

2009-03-27T11:34:00.000-07:00

QTP 6.5:

To successfully install and run QTP 6.5, following minimum system requirements are required :

Computer/Processor:	IBM-PC or compatible with a Pentium® II 266 MHz microprocessor (366 MHz recommended).
Operating System:	Windows^® 98 Second Edition, Windows^® 2000—Service Pack 3, Windows NT^® 4.0—Service Pack 6a, Windows^® Me, or Windows^® XP—Service Pack 1.
Memory:	128 MB of RAM (256 MB recommended)
Free Hard Disk Space:	150 MB of free disk space for a compact installation or 200 MB for a typical or complete installation
Browser:	Microsoft Internet Explorer 5.0–6.0.

Supported Environments

QuickTest Professional supports creating, recording, and running tests in the environments described below.

Windows Applications

1. Win32 API
2. MFC

Basic Applications

Visual Basic 6.0

Browsers

• Microsoft Internet Explorer 5.01–6.0 (required)
• Netscape Navigator 4.06–4.7x (optional)
• Netscape 6.1, Netscape 6.22, and Netscape 6.23 (optional)
• AOL 5.0 and 6.0 (optional)

ActiveX Grid Controls

In addition to basic support of ActiveX properties and methods, QuickTest Professional supports context-sensitive recording and verification on the following ActiveX Grid controls:

Name	ProgId
FarPoint Spreadsheet 2.5	FPSpread.Spread.1
FarPoint Spreadsheet 3.0	FPSpread.Spread.2
FarPoint Spreadsheet 3.5	FPSpread.Spread.3
FarPoint Spreadsheet 6.0	FPSpread.Spread.4
FarPoint Spreadsheet 3.0 (OLEDB)	FPSpreadADO.fpSpread.2
FarPoint Spreadsheet 3.5 (OLEDB)	FPSpreadADO.fpSpread.3
FarPoint Spreadsheet 6 (OLEDB)	FPSpreadADO.fpSpread.4
Microsoft Grid 1.0	MSGrid.Grid
Microsoft DataBound Grid 5.0	MSDBGrid.DBGrid
Microsoft Flex Grid 6.0	MSFlexGridLib.MSFlexGrid.1
Sheridan Data Grid 2.0	SSDataWidgets.SSDBGridCtrlApt.1
Sheridan Data Grid 3.1	SSDataWidgets.SSDBGridCtrlApt.3
Apex True DataBound Grid 5.0	TrueDBGrid50.TDBGrid
Apex True DataBound Grid 6.0	TrueDBGrid60.TDBGrid
Apex True OLE DB Grid 6.0	TrueOleDBGrid60.TDBGrid

ActiveX Calendar Controls

In addition to basic support of ActiveX properties and methods, QuickTest Professional supports context-sensitive recording and verification on the following ActiveX Calendar controls:

Name	ProgId
Microsoft Date and Time Picker Control 6.0 (SP4)	MSComCtl2.DTPicker.2
Microsoft MonthView Control 6.0 (SP4)	MSComCtl2.MonthView.2

Multimedia Applications

QTP 6.5 supports testing on the following multimedia applications:

• Microsoft Windows MediaPlayer controls, version 6.0 and higher

• RealPlayer controls supported for Internet Explorer browsers (the controls within applications containing browser controls are not supported)

• Macromedia Flash 4 or 5 objects that are ActiveX controls in Internet Explorer. You can also test Macromedia Flash 6 clips containing only Flash 4 or 5 commands.

Additional Environments

QuickTest Professional add-ins support other environments such as Java, .NET Windows and Web Forms, SAP solutions, Oracle, Siebel, PeopleSoft, Web Services, and terminal emulator applications. For more information about QuickTest Professional add-ins, contact your sales representative or Mercury Interactive Customer Support.

Note for QuickTest Professional 6.0 and earlier:

Java support and Oracle support are now available as separate add-ins to QuickTest Professional 6.5 and are no longer part of the core product.

QTP Environment Compatibility

2009-03-27T11:26:00.001-07:00

QTP (version) supports a wide range of working environments and thereby can be used for practically any application.

Core Environments Supported by QTP:

- Windows applications (MFC)
- Visual Basic
- Java
- ActiveX

Enterprise Applications:

- SAP
- Siebel
- PeopleSoft
- Oracle

Web Technologies:

- HTML
- DHTML
- JavaScript

Browsers:

- Internet Explorer
- Netscape
- AOL

Emerging Technologies:

- .NET winforms, webforms, web services
- J2EE Web services
- XML, WSDL, UDDI

Terminal Emulators:

- 3270
- 5250
- VT100

Server Technologies:

- Oracle
- Microsoft
- IBM
- BEA
- ODBC
- COM / COM+

Multimedia:

- Flash
- RealAudio / RealVideo
- Windows Media Player

Operating Environment

Operating Systems Supported:	Windows XP/2000/NT Windows 95/98/ME
Databases Supported:	(Not Applicable)
Networks Supported:	TCP/IP
Programming Languages Supported:	JavaScript Java HTML Visual Basic (VB) XML
Middleware Supported:	Microsoft .NET

Guidelines followed for identification of Test Cases for Automation

2009-03-27T11:23:00.000-07:00

• Tests that need to run once and those that need frequent human intervention are usually not worth the investment to automate and have not been considered for automation.

• As Automated testing can be used to verify the performance of application paths that are used with a high degree of frequency when the software is running in full production e.g. creating customer records, Invoicing and other high volume activities where software failure would occur frequently have been considered.

• Mission critical processes like core activities like sales order processing are prime candidates for automated testing and have been considered for automation.

• Repetitive Testing

• Applications with Long Life span – Longer the application in production greater the benefits from automation.

• Avoiding dynamic screens. Though possible to automate this increases the complexity of the script.

• Avoiding screens where objects are created dynamically

• Avoiding business scenarios where complex hardware is involved

• Selecting a row in a table results in an additional challenge from. Some automation tools provide the facility to read each row in a table and for focusing on a specific row. If the numbers of rows were very high the execution time of the script would be high. This leads to performance issues of the recorded script. Hence, it is better to prove the business scenario wherein tables with row selections figure by identifying a fixed row number. This scenario is faced very frequently in enterprise applications as in pricing tables and leads to the complexity of the script and subsequently the effort.

• Avoiding scenarios that require high degree of coding while automating so that script’s complexity is reduced and high maintainability of the script is ensured.

Automation Framework

2009-03-26T09:46:00.000-07:00

For Quality deliverables, important things that should be followed are:

Following common coding structure for all the scripts
Consistent coding conventions
Use of Reusability for making code efficient and minimal
Efficient use of Object Repository
Use of Error and Exception handling Functions
Use of Data table object, Environment variables for using data

For example in the Unilever project:

Coding Structure used is that there will a main Action for all the scripts which is named as corresponding Test case name, This Action intern will call all the other actions (Each Transaction used in the script would be an action) in the script. Importing and Exporting of sheets is also done in this main action. Importing of sheets is done at the beginning before calling other actions and exporting of sheets is done at the last. Sheets corresponding to all the actions in the scripts are imported, so that the data in the fields of the Imported sheets are used as input data to the script, output data from the script is also collected and exported to the corresponding sheet.

There are many transactions which are reused in the scripts, similar transactions (Actions) are made as reusable so that its not required to record those transactions again and again, which ever transaction was common among scripts, were recorded in one script and is reused in all the scripts where the transaction is required.

Error handling in the unilever automation is done by using Recovery Scenario where each Recovery scenario calls a function which handles the recovery by exiting all the other transactions (actions) when recovery fires. Major types of Recovery used in this project where Popup Window, Object state and on Error Recoveries. In Error handling using Recovery, all the common types of exceptions or errors are given common Recovery scenarios using regular expressions, which minimized the number of Recovery scenarios and Functions used.

Approach for Test Automation

2009-03-26T04:48:00.000-07:00

Description

Approach for Test Automation is used for building a strategy for automation starting from the Requirement phase till the deployment phase. Approach for automation begins with finding out the conditions and business rules given by the client and grouping similar conditions, business rules together as Test cases or Test Scenarios.

Steps involved in Approach for Test Automation are as follows:

• Requirement gathering from the client
• Understanding and Analyzing the Requirement
• Grouping the requirement into Test cases
• Preparing the Design for Automation
• Building Scripts depending on the Design
• Review of Scripts at Offshore
• Delivery to the Client

For example in the Unilever project:

Since it is Project for Automation of SAP, Team was divided into two,

1. SAP Consultants.
2. Testing Team.

Requirement gathering from the client included knowledge transfer at onsite, where all the transactions including the customized transactions where explained to the SAP Consultants of satyam, Under standing of requirements was done at the client side, Depending on the flow of transactions, all the transactions where grouped together as different scenarios. While SAP Consultants where onsite for gathering Requirements, Work done at the offshore was to analyze on the appropriate version of the QTP Tool to be used and to get licenses for QTP, user accounts for SAP access, Installation of QTP and SAP.

All the Identified Scenarios which consists of different transactions where explained to Testing Team. Then common functionalities where identified, and grouped together as different Test cases.

After defining different Test cases, design for automation of scripts was done, where Reusability was one of the main aspects, where all the transactions, which are common in the scenarios, are identified as Reusable transactions.