Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Showing posts with label keyword driven testing. Show all posts
Showing posts with label keyword driven testing. Show all posts

Keyword Driven Automation Object Repository in QTP

Setting Up Object Repositories


In this step, you build one or more object repositories and ensure that all objects have clear names that follow any predetermined naming conventions defined by your organization.

You can create object repositories using QuickTest functionality to recognize and learn the objects in your application, or you can manually define objects. The object repository should contain all the objects that are relevant for the tests using this infrastructure.

By creating and populating shared object repositories that can be associated with multiple actions, you can use the same object repository in multiple tests. By maintaining all objects that are relevant to an area of an application within one shared object repository, and by associating that object repository with all relevant actions, changes to the application can be reflected in the object repository without the need to update tests.

Before you create a new object repository, verify whether an object repository containing the objects you are testing already exists. If not, you can create a new object repository or add objects to an existing one.

Creating shared object repositories for the test automation infrastructure can include the following tasks:
  • Change the way that QuickTest identifies specific objects, if needed. This is particularly helpful when your application contains objects that change frequently or are created using dynamic content, for example, from a database. This task needs to be done before you create your object repository. For more information, see Configuring Object Identification.
  • Decide how you want to organize your object repositories. For individual tests, you can work with the individual action's object repositories, or you can work with a common (shared) object repository that can be used with multiple tests. If you are new to testing, you may want to keep the default object repository per-action setting for tests. As you feel more comfortable with the basics of test design, you may want to take advantage of the shared object repository option.
  • If you decide to work with shared object repositories, you need to determine how many shared object repository files are required for your application. You also need to determine which shared object repository will be used for each area of your application.
    For more information, see Managing Test Objects in Object Repositories.
  • Add (learn) objects from your application. You instruct QuickTest to learn the objects in your application according to filters that you define. For more information, see Adding Test Objects to a Local or Shared Object Repository.
  • If necessary, create new objects to represent objects that do not yet exist in your application. Then update the properties and values of these objects as necessary after they exist in the application. For more information, see Defining New Test Objects.
  • Ensure that objects in the object repository have names that are easy for application testers to recognize and that follow any established object naming guidelines. This helps make both test creation and maintenance easier over time.
  • Copy or move objects from one repository to another, as needed. For more information, see Managing Object Repositories.
  • Merge objects added to local repositories by application testers into the shared object repositories of the automation infrastructure. You can also merge two or more existing repositories. For more information, see Merging Shared Object Repositories.

Keyword Driven Automation : QTP

Analyzing Your Application


In this step, you analyze your application to determine your testing needs. This step is divided into multiple tasks:
  • Determine the development environments that QuickTest needs to support. From the perspective of QuickTest, your application comprises windows containing a hierarchy of objects that were created in one or more development environments. QuickTest provides support for these environments using add-ins.
  • You load QuickTest add-ins when QuickTest opens by using the Add-in Manager dialog box. You can check which add-ins are loaded by choosing Help > About QuickTest Professional. For more information, see the HP QuickTest Professional Add-ins Guide.
  • Prepare the information that QuickTest needs to identify objects in your application and to (optionally) open your application at the beginning of a run session. You need to know the URL, the executable file name and path, or other command-line information. Later, you will enter this in Record and Run Settings dialog box. For more information, see the sections describing the Record and Run options for your testing environment in the HP QuickTest Professional Add-ins Guide.
  • Analyze the various business processes that customers perform while using your application to determine the actions you need to create. You create an action for each sub-process, or task, a customer might perform.
  • Navigate through your application from a customer's perspective and perform the tasks that customers might perform. Each process you perform in your application will be represented as a test in QuickTest. You can create your tests now, or you can wait until you are ready to add steps to your tests
    As you perform a process, try to compartmentalize or "chunk" it into modular units.

Example

An application that enables users to purchase items online might contain various business processes, including registering on the site and purchasing items. Each process may require one or more tasks—you create actions based on these tasks. For example, registering on the site may be a simple process requiring only one action, whereas purchasing items may be more complex, requiring several actions, such as a Login action, a Browse action, an AddToCart action, a PurchaseItems action, and a Logout action.

By creating separate reusable actions for each task, you can include calls to the same actions from multiple tests. For example, you may want to include a Login action in many of your tests.

You can create empty actions now to set up a skeleton infrastructure for your tests, or you can create them when you are ready to add steps to your actions. For more information, see Working with Actions.

You may also want to create a single test storing all actions relevant for an application. Then all other tests can call the actions stored in this central repository. This helps with test structure and maintenance.

Tip: As you plan your tests and actions, keep in mind that short tests and actions that check specific functions of the application or complete a transaction are better than long ones that perform several tasks.

Keyword Driven Automation In QTP

Understanding the Keyword-Driven Methodology


Keyword-driven testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.What is Keyword driven Testing.

This section provides a general overview of the steps you perform when planning and implementing your tests.


Stage 1: Analyzing Your Application  :
 

Before you begin creating a test, you need to analyze your application and determine your testing needs.

First, determine the development environments in which your application controls were developed, such as Web, Java, or .NET, so that you can load the required QuickTest add-ins. 


Then determine the functionality that you want to test. To do this, consider the various activities that customers perform in your application to accomplish specific tasks. Which objects and operations are relevant for the set of business processes that need to be tested? Which operations require customized keywords to provide additional functionality?

While you are thinking about the business processes you want to test, consider how you can divide these processes into smaller units, which will be represented by your test's actions. Each action should emulate an activity that a customer might perform when using your application.

As you plan, try to keep the amount of steps you plan to include in each action to a minimum. Creating small, modular actions helps make your tests easier to read, follow, and maintain. 




To complete the infrastructure that is part of the planning process, you need to build the set of resources to be used by your tests, including shared object repositories containing test objects (which are representations of the objects in your application), function libraries containing functions that enhance QuickTest functionality, and so on. For more information, see Managing Test Objects in Object Repositories and Working with User-Defined Functions and Function Libraries.


At this stage you also need to configure QuickTest according to your testing needs. This can include setting up your global testing preferences, your run session preferences, any test-specific preferences, and recovery scenarios. You can also create automation scripts that automatically set the required configurations (such as the add-ins to load) on the QuickTest client at the beginning of a run session. For more information, see Automating QuickTest Operations. 


Lastly, you create one or more tests that serve as action repositories in which you can store the actions to be used in your tests. Generally, you create an action repository test for each area of your application to be tested. Storing all of your actions in specific tests enables you to maintain your actions in a central location. When you update an action in the action repository, the update is reflected in all tests that contain a call to that action. When you run a test, only the relevant action repository tests are loaded. 


You then associate the shared object repositories with the relevant actions. This enables you to later insert steps using the objects stored in the object repositories. 


When you create your tests, you insert calls to one or more of the actions stored in this repository. 


 

In this stage, you add steps to the actions in your test action repository.

Before you begin adding steps, make sure that you associate your function libraries and recovery scenarios with the relevant tests, so that you can insert steps using keywords.

You can create steps using the keyword-driven functionality available in the table-like, graphical Keyword View—or you can use the Expert View, if you prefer to program steps directly in VBScript. You can add steps to your test in one or both of the following ways:

  • Drag objects from your object repository or the from Available Keywords pane to add keyword-driven steps in the Keyword View or Expert View. The object repository and Available Keywords pane contain all of the objects that you want to test in your application. (You create one or more object repositories when you prepare the testing infrastructure, as described in Stage 2: Preparing the Testing Infrastructure.)
  • When you drag an object into the Keyword View, a step is created in the action with the default operation for that object. For example, if you drag a button object into the Keyword View, the click operation is automatically defined for the step. You can then modify the step as needed. For more information, see Working with the Keyword View and Adding Keywords to Your Test. Advanced users can also add steps using the Expert View. For more information, see Working in the Expert View and Function Library Windows. 

  • Record on your application.
  • As you navigate through your application during a recording session, QuickTest graphically displays each step you perform as a row in the Keyword View. A step is something that causes or makes a change in your application, such as clicking a link or image, or submitting a data form. In the Expert View, these steps are displayed as lines in a test script (VBScript). The Documentation column of the Keyword View also displays a description of each step in easy-to-understand sentences. For more information, see Working with the Keyword View.


You can enhance the testing process by modifying your test with special testing options and/or with programming statements, such as:

  • Insert checkpoints and output values into your test.
  • A checkpoint checks specific properties or other characteristics of an object and enables you to identify whether or not your application is functioning correctly. For more information, see Understanding Checkpoints.
    You can also use output values to extract data from your test. An output value is a value retrieved during the run session and entered into your Data Table or stored in a variable or a parameter. You can subsequently use this output value as input data in your test. This enables you to use data retrieved during a run session in other parts of the test. For more information, see Outputting Values.

  • Broaden the scope of your test by replacing fixed values with parameters.
  • When you test your application, you can parameterize your steps to check how your application performs the same operations with different data. You may supply data in the Data Table, define environment variables and values, define test or action parameters and values, or instruct QuickTest to generate random numbers for current user and test data.
    When you parameterize your test, QuickTest substitutes the fixed values in your test with the values stored in the relevant parameters. When you use Data Table parameters, QuickTest uses the values from a different row in the Data Table for each iteration of the test or action. (Each run session that uses a different set of parameterized data is called an iteration.) For more information, see Parameterizing Values.

  • Add user-defined functions by creating function libraries and calling their functions from your test. For more information, see Working with User-Defined Functions and Function Libraries.

  • Use the many functional testing features included in QuickTest to enhance your test and/or add programming statements to achieve more complex testing goals. For more information, see Adding Steps Containing Programming Logic.


After you create your test, you can perform different types of runs to achieve different goals.

  • Run your test to debug it. You can control your run session to help you identify and eliminate defects in your test. You can use the Step Into, Step Over, and Step Out commands to run your test step by step. You can begin your run session from a specific step in your test, or run the test until a specific step is reached. You can also set breakpoints to pause your test at predetermined points. You can view or change the value of variables in your test each time it stops at a breakpoint in the Debug Viewer. You can also manually run VBScript commands in the Debug Viewer. For more information, see Debugging Tests and Function Libraries.

  • Run your test to check your application. The test starts running from the first line in your test and stops at the end of the test. While running, QuickTest connects to your application and performs each operation in your test, including any checkpoints, such as checking any text strings, objects, tables, and so forth. If you parameterized your test with Data Table parameters, QuickTest repeats the test (or specific actions in your test) for each set of data values in the Data Table. For more information, see Running Tests.

  • Run your test to update it.

    • You can run your test using Maintenance Run Mode when you know that your application has changed, and you therefore expect that QuickTest will not be able to identify the objects in your test. When you run a test in Maintenance Run Mode, a wizard opens for steps that fail because an object could not be found in the application. The wizard then guides you through the steps of resolving the issue, and, after you resolve the issue, the run continues. For more information, see Maintaining Tests.

    • You can run your test using Update Run Mode to update the property sets used for test object descriptions, the expected checkpoint values, the data available to retrieve in output values, and/or the Active Screen images and values.


After you run your test, you can view the results of the run in the Test Results window. You can view a summary of your results as well as a detailed report. If you captured still images or movies of your application during the run, you can view these from the Screen Recorder tab of the Test Results window. For more information, see Viewing Run Session Results. If you enabled local system monitoring for your test, you can view the results in the System Monitor tab of the Test Results window. For more information, see Viewing System Monitor Results. 


Finally, you can report defects detected during a run session. If you have access to Quality Center, the HP centralized quality solution, you can report the defects you discover to the project database. You can instruct QuickTest to automatically report each failed step in your test, or you can report them manually from the Test Results window. For more information, see Integrating with Quality Center.


Shipping The Test In QTP

Zipping a Test


QuickTest tests contain a series of configuration, run-time, setup data, and (optionally) Active Screen files. QuickTest saves these files together with the test. You can zip these files to conserve space and make the tests easier to transfer.

To zip a test:
  1. Do one of the following:
    • Select File > Export Test to Zip File to open the Export to Zip File dialog box.
    • Select the Archive test and resource files in a .zip file check box in the Save Test with Resources dialog box (File > Save Test with Resources). For more information, see The Save Test with Resources Dialog Box.
  2. Type a zip file name and path, or accept the default name and path, and click OK. QuickTest zips the test and its associated files.

Unzipping a Test


You can unzip a test when needed.

To unzip a zipped test:
  1. Select File > Import Test from Zip File. The Import from Zip File dialog box opens.
  2. Enter or select the name of the zip file that you want to unzip, choose a target folder into which you want to unzip the files, and click OK. QuickTest unzips the test and its associated files.

Resource Handling In QTP

The Save Test with Resources Dialog Box


How to hande the resurcs in QTP.



Description

Enables you to save a full copy of a test and its resource files to a local drive or other storage device, eliminating the need for network or Quality Center connections.

How to Access
  • Select the File > Save Test with Resources menu command.
  • Click the Save Test with Resources toolbar button .

Important Information

Before you create a copy of the test:
  • Resolve any missing resources.
  • Save the original test.
  • Make sure that all files associated with the source test are writable.
  • Make sure you have write permissions for the folder in which you want to create a copy of the test.

After you make a copy of the test:
  • A report is displayed in HTML format, listing:
    • the name of the test, the name of the user that saved this copy of the test, and the date on which the test was copied.
    • a record for each resource that was copied with the test, specifying:
      -- the name of the resource
      -- the type of resource (for example, function library)
      -- the path from which the resource was copied
      -- the status of the copied resource
         (for example, the resource was saved successfully)
      -- the current location of the copied resource

You can also open this file from the copied test's root folder.
  • The copied test becomes the active test in the QuickTest window.
  • All links to the source files are severed. Therefore, any modifications you make to the copied test are applied only to the copied test.

Learn More

Conceptual overview: Creating Portable Copies of Your Tests

Additional related topic: Guidelines for Working with Tests Created Using an Earlier Version of QuickTest

Save Test with Resources Dialog Box Options





Option

Description

Save Location

Specifies the root folder in which to save the test. By default, the root folder is <QuickTest installation folder>\Tests, however, you can specify any folder on a local, network, or portable drive.

Important: The folder you specify must not already contain a sub-folder with the same name as the test.

Resources tree

Lists the external resources that are currently associated with or attached to your test.

Save Active Screen files

(Relevant only for recorded tests.) Instructs QuickTest to save any existing Active Screen files with your test.

Clearing the Save Active Screen files check box can be especially useful for conserving disk space if you have finished designing the test and are using the test only for test runs.

Note: If you clear this box, your Active Screen files will not be copied over with the test and its resources, and you will not be able to edit your test using the options that are normally available from the Active Screen.

Tip: If you clear the Save Active Screen files check box and then later want to edit your test using Active Screen options, you can regenerate the Active Screen information by performing an Update Run operation. For more information, see Updating a Test Using the Update Run Mode Option.

Archive test and resource files in a .zip file

Creates a .zip file of the test and its resources, and stores the .zip file in the folder you specified in the Save Location box.

For more information, see Zipping a Test.

Test Creation Opening In QTP

How : Creating a New Test


To create a new test, click the New button or select File > New > Test. A new test opens, with a new action selected in the Keyword View. You are ready to start creating your test.

Opening an Existing Test


You can open an existing test to enhance or run it.

To open a test stored in Quality Center, QuickTest must be connected to the Quality Center project. For more information, see Integrating with Quality Center.

If the test you select was last saved in an older version of QuickTest, you may be asked whether to convert the test to the current version or view it in read-only format. For more information, see Considerations for Opening Tests Created in Previous Versions of QuickTest.

To open an existing test:
  1. (Optional) Connect to a Quality Center server and project. For more information, see Connecting to and Disconnecting from Quality Center.
  2. Select File > Open > Test, or click the Open down arrow and select Test. The Open Test dialog box opens.
  3. In the sidebar, select the location of the test, for example, File System or Quality Center Test Plan.
  4. Browse to and select a test. You can select the Open in read-only mode option at the bottom of the dialog box. Click Open. The test opens and the title bar displays the test name.
  5. Note: If the test is stored in a version control-enabled Quality Center project, the Open button contains a down arrow, enabling you to open the test and immediately check it out. For more information, see Checking Assets Out of the Version Control Database.

Understanding Absolute and Relative Paths In QTP

Understanding Absolute and Relative Paths


You can save QuickTest resources, such as shared object repositories, function libraries, recovery scenarios or environments, using absolute or relative paths.

Note: If you are working with the Resources and Dependencies model with Quality Center 10.00, specify an absolute Quality Center path. For more information, see Considerations for Working with Relative Paths in Quality Center.
  • An absolute path describes the full path to a specific file starting from a fixed location such as the root directory, or the drive on which the file is located, and contains all the other sub-directories in the path. An absolute path always points to the specified file, regardless of the current directory.
  • A relative path describes the path to a specific file starting from a given directory, and is generally only a portion of the absolute path. A relative path therefore specifies the location of the file relative to the given location in the file system.

Using relative paths means that the paths remain valid when files or folders containing files are moved or copied to other locations or computers, provided that they are moved within the same folder structure. For this reason, we recommend that you use relative paths when saving resources in QuickTest.

For example, consider a QuickTest resource file named FunctionLibrary1.qfl located in C:\Current_Version\Libraries. The absolute path to the file is C:\Current_Version\Libraries\FunctionLibrary1.qfl. The relative path to the file from within the folder named Libraries is specified using only the name of the file, FunctionLibrary1.qfl. Alternatively, the relative path to the file from within another folder, such as C:\Current_Version\Libraries\MyFiles, would be Libraries\FunctionLibrary1.qfl.

Using a relative path, you could copy the FunctionLibrary1.qfl file from C:\Current_Version\Libraries to an updated version in C:\New_Version\Libraries, and the path used by QuickTest would remain valid.

In addition, relative paths are quicker to type and, being shorter, minimize any chance for error.

For more information, see Using Relative Paths in QuickTest.

Note: Prior to QuickTest 9.0, if you specified a path for a resource starting with \.., it was considered to be a relative path. In QuickTest 9.0 and later, a path that starts with \.. is considered to be a full path, with the backslash representing the root folder of the current drive.

If you defined paths starting with \.. using earlier versions of QuickTest, you should change the path to be a standard relative path by removing the backslash (\).

Enhancing Your Test In QTP

Enhancing Your Test


You can use a variety of options to enhance your existing tests. This section describes some of the ways in which you can enhance your existing tests.

Checkpoints

You can add checkpoints to your test. A checkpoint is a step in your test that compares the a specified item during a run session with the values stored for the same item within the test. This enables you to identify whether or not your application is functioning correctly. There are several different checkpoint types. For more information on creating checkpoints, see Understanding Checkpoints.

Tip: You can also use the CheckProperty method, which enables you to verify the property value of an object without using the checkpoint interface. For more information, see HP QuickTest Professional Object Model Reference.

Parameterization

You can parameterize your test to replace fixed values with values from an external source during your run session. The values can come from a Data Table, environment variables you define, or values that QuickTest generates during the run session. For more information, see Parameterizing Values.

Output Values

You can retrieve values from your test and store them in the Data Table as output values. You can subsequently use these values as an input parameter in your test. This enables you to use data retrieved during a test in other parts of the test. For more information, see Outputting Values.

Actions

You can divide your test into actions to streamline the testing process of your application. For more information, see Working with Actions.

Programming Statements

You can use special QuickTest options to enhance your test with programming statements. The Step Generator guides you step-by-step through the process of adding recordable and non-recordable operations (methods and properties) to your test. You can also synchronize your test to ensure that your application is ready for QuickTest to perform the next step in your test, and you can measure the amount of time it takes for your application to perform steps in a test by defining and measuring transactions. For more information, see Adding Steps Containing Programming Logic.

You can also manually enter standard VBScript statements, as well as statements using QuickTest test objects and operations, in the Expert View. For more information, see Working in the Expert View and Function Library Windows.

Understanding Your Test QTP

Understanding Your Test 

When you create a test, QuickTest creates a graphical representation of the steps you perform on your application. These steps are displayed in the Keyword View tab.
The following is a sample test of a login procedure to the Mercury Tours site, the sample Web site.

The table below provides an explanation of each step in the Keyword View.

Step
Description
Action1 is the action name.
The browser invokes the Welcome: Mercury Tours Web site.
Welcome: Mercury Tours is the name of the Web page.
userName is the name of the edit box. Set is the method performed on the edit box. tutorial is the value of the edit box.
password is the name of the edit box. SetSecure is an encryption method performed on the edit box. 4082986e39ea469e70dbf8c5a29429fe138c6efc is the encrypted value of the password.
Sign-In is the name of the image link. Click is the method performed on the image. 2, 2 are the x- and y-coordinates where the image was clicked.

In the Expert View, these same steps are displayed using a VBScript program based on the QuickTest object model.
Browser("Welcome: Mercury Tours").Page("Welcome: Mercury Tours").WebEdit("userName").Set "tutorial"
Browser("Welcome: Mercury Tours").Page("Welcome: Mercury Tours").WebEdit("password").SetSecure
"4082986e39ea469e70dbf8c5a29429fe138c6efc"
Browser("Welcome: Mercury Tours").Page("Welcome: Mercury Tours").Image("Sign-In").Click 2,2

KeyWord Driven Or Recording Machanism in QTP

Deciding Which Methodology to Use - Keyword-Driven or Recording


You can create the steps in your tests using the keyword-driven methodology, recording, or a combination of both.

Recording Tests

Recording can be useful in the following situations:
  • Recording helps novice QuickTest users learn how QuickTest interprets the operations you perform on your application, and how it converts them to QuickTest objects and built-in operations.
  • Recording can be useful for more advanced QuickTest users when working with a new application or major new features of an existing application (for the same reasons described above). Recording is also helpful while developing functions that incorporate built-in QuickTest keywords.
  • Recording can be useful when you need to quickly create a test that tests the basic functionality of an application or feature, but does not require long-term maintenance.

For information on recording tests, see Creating Tests Using the Recording Mechanism.

Creating Tests Using Keyword-Driven Testing

Keyword-driven testing advantages include the following:
  • Keyword-driven testing enables you to design your tests at a business level rather than at the object level. For example, QuickTest may recognize a single option selection in your application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.
  • By incorporating technical operations, such as a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes.
  • Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
  • When you record tests, you may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, you select the objects for your steps from the existing object repository. When you need a new object, you can add it to your local object repository temporarily, but you are also aware that you need to add it to the shared object repository for future use.
  • When you record a test, QuickTest enters the correct objects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. Although this makes it easier to create tests quickly, such tests are harder to maintain when the application changes and often require re-recording large parts of the test.
  • When you use a keyword-driven methodology, you select from existing objects and operation keywords. Therefore, you must be familiar with both the object repositories and the function libraries that are available. You must also have a good idea of what you want your test to look like before you begin inserting steps. This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance.
  • Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product. Using keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle.

About Creating Tests In QTP

About Creating Tests In Quick Test Pro(QTP)


You can create tests using the keyword-driven methodology, step recording, or a combination of both.

Creating tests using the keyword-driven methodology requires an infrastructure for all of the required resources. Resources include shared object repositories, function libraries, and recovery scenarios. Setting up the infrastructure requires in-depth knowledge of your application and a high level of QuickTest expertise. 


Although setting up the infrastructure may initially require a longer time-investment in comparison to recording tests, using the keyword-driven methodology enables you to create tests at a more application-specific level and with a more structured design. This enables you to maintain your tests more efficiently and provides you with more flexibility than a recorded test. 


In some cases, you may want to let QuickTest generate test steps by recording the typical processes that you perform on your application. As you navigate through your application, QuickTest graphically displays each step you perform as a row in the Keyword View. A step is anything a user does that changes the content of a page or object in your application, for example, clicking a link or typing data into an edit box. Recording may be easier for new QuickTest users or when beginning to design tests for a new application or a new feature. 


While creating your test, you can insert checkpoints. A checkpoint compares the value of an element captured when the object was saved in the object repository, with the value of the same element captured during the run session. This helps you determine whether or not your application is functioning correctly. For more information, see Understanding Checkpoints. 


When you test your application, you may want to check how it performs the same operations with different data. This is called parameterizing your test. You can supply data in the Data Table, define environment variables, instruct QuickTest to generate random numbers, and so on. For more information, see Parameterizing Values.

After creating your initial test, you can further enhance it by adding and modifying steps in the Keyword View or Expert View.