You can create a test using the keyword-driven methodology, which enables you to select keywords to indicate the operations you want to perform on your application. This enables you to create structured tests that are easier to update and maintain over time.
The keyword-driven methodology is especially useful for organizations that have both technical and less technical users because it offers a clear division of automation tasks. This enables a few experts to maintain the resource framework while less technical users design and maintain automated test steps. Additionally, once the basic infrastructure is in place, both types of users can often do their tasks simultaneously.
Before you begin creating tests, you need to plan your tests to ensure that your tests cover your testing requirements.
Tip: You can also create a test by recording the operations you perform on your application, as described in Creating Tests Using the Recording Mechanism. After you create your test, you can enhance it using checkpoints and other special testing options.
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.
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 QTP 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.
Stage 2: Preparing the Testing Infrastructure
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 QTP functionality, and so on.
At this stage you also need to configure QTP 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 QTP client at the beginning of a run session.
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.
Stage 3: Adding Steps to Your Actions
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.
Record on your application.
- Insert checkpoints and output values into your test.
- Broaden the scope of your test by replacing fixed values with parameters.
- Add user-defined functions by creating function libraries and calling their functions from your test.
- Use the many functional testing features included in QTP to enhance your test and/or add programming statements to achieve more complex testing 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.
- 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, QTP 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, QTP repeats the test (or specific actions in your test) for each set of data values in the Data Table.
- 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 QTP 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.
- 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.
As you navigate through your application during a recording session, QTP 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.
Stage 4: Enhancing Your Test
You can enhance the testing process by modifying your test with special testing options and/or with programming statements, such as:
A checkpoint checks specific properties or other characteristics of an object and enables you to identify whether or not your application is functioning correctly.
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.
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 QTP to generate random numbers for current user and test data.
When you parameterize your test, QTP substitutes the fixed values in your test with the values stored in the relevant parameters. When you use Data Table parameters, QTP 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.)
Stage 5: Running and Debugging Your Test
After you create your test, you can perform different types of runs to achieve different goals.
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.
If you enabled local system monitoring for your test, you can view the results in the System Monitor tab of the Test Results window.
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 QTP to automatically report each failed step in your test, or you can report them manually from the Test Results window.
