Software Testing Experience

Mercury QuickTest Professional is the advanced solution for functional test and regression test automation. This next-generation automated testing solution deploys the concept of keyword-driven testing to enhance test creation and maintenance. 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.

Using the keyword-driven approach, test automation experts have full access to the underlying test and object properties, via an integrated scripting and debugging environment that is round-trip synchronized with the Keyword View.

You create a test either by building an object repository and adding steps manually or by recording a session on your application. You can create steps using the table-like, graphical Keyword View using keyword-driven functionality—or you can use the Expert View, if you prefer programming steps directly in VBScript.

The Keyword View enables you to create and view the steps of your test in a keyword-driven, modular, table format. The Keyword View is comprised of a table-like view, in which each step is a separate row in the table, and each column represents different parts of the steps. You can modify the columns displayed to suit your requirements. You create and modify tests by selecting items and operations in the Keyword View and entering information as required. Each step is automatically documented as you complete it, enabling you to view a description of your test steps in understandable English.

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

In comparison to recording, the keyword-driven methodology generally requires a longer time-investment and at least one automation expert with a high-level of QuickTest expertise to prepare the infrastructure required for your tests, but once the infrastructure is in place, tests can be created at a more application-specific level and with a more structured design. Additionally, all the tests for a given application can be maintained more efficiently and with more flexibility than a recorded test.

Creating a Test Using 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. The keyword-driven testing methodology divides test creation into two stages:
Preparing a set of testing resources (the test automation infrastructure).

• Preparing the test automation infrastructure includes a planning stage and an implementation stage.
  
• Creating tests in the QuickTest Keyword View by selecting the keywords (objects and/or operations) that represent the application functionality you want to test.
  

Planning Stage

• Analyzing the application and determining which objects and operations are used by the set of business processes that need to be tested.
  
• Determining which operations require customized keywords to provide additional functionality, to achieve business-level clarity, and/or to maximize efficiency and maintainability.
  

Implementation Stage

• Building the object repository and ensuring that all objects have clear names that follow any predetermined naming conventions. 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.
  
• Developing and documenting business-level keywords in function libraries. Creating function libraries involves developing customized functions for the application you want to test. You may want to develop functions to test special application functionality that is not already supplied by the methods in the QuickTest object model. It is also useful to wrap existing methods and functions together with additional programming to create application-specific functions for testing operations or sequences that are commonly performed in your application. The functions you create will be available either as extra keywords or as replacements for built-in QuickTest keywords during the test creation stage.
  

Although this methodology requires more planning and a longer initial time-investment than going directly to the test creation stage and recording your steps, this methodology makes the test creation and test maintenance stages more efficient and keeps the structure of individual tests more readable and easier to modify.

By encapsulating much of the complex programming into function libraries, and by making these functions flexible enough to use in many testing scenarios (through the use of function parameters that control the way the functions behave), one or a few automation experts can prepare the keywords that many application testers who are less technical can include in multiple tests. This also makes it possible to update testing functionality without having to update all the tests that use the keywords.

In a similar fashion, by maintaining all objects that are relevant to a particular application or area of an application within one shared object repository, and by associating that object repository with all relevant tests, changes to the application can be reflected in the object repository without the need to update tests.

After the object and function library keywords are ready, application testers can use these keywords to build keyword-driven tests.

Recorded tests tend to be specific to a single procedure or set of procedures. When the application changes, especially when it changes significantly from one version to another, much of the test often needs to be rerecorded.

By creating your tests with a keyword-driven methodology in mind, your tests become more modular, focusing on the operations to test using both QuickTest built-in keywords and your own user-defined keywords. Additionally, because it is possible to add objects to the object repository before they exist in an application, it is possible to begin preparing your automated keyword-driven tests even before a build containing the new objects is available.

Developing a Keyword-Driven Automation Infrastructure

One or a few automation experts usually develop the test automation infrastructure that all tests related to a certain application or functionality will use. The automation infrastructure usually includes one or more shared object repositories and one or more function libraries. The information in the sections below gives you some guidance on the main tasks involved in creating these resources and describes where you can find detailed documentation for these tasks. After the test automation infrastructure is ready, the application testers can begin designing their keyword-driven tests by selecting objects and operation keywords in the Keyword View.

Creating a Shared Object Repository

The tasks involved in creating a shared object repository for the test automation infrastructure can include:

• Adding (learning) objects from your application.
  
• Creating new objects to represent objects that do not yet exist in your application and then later updating the properties and values of these objects as necessary once they exist in the application.
  
• Ensuring that objects in the object repository have names that are easy for application testers to recognize and that follow any established object naming guidelines.
  
• Copying or moving objects from one repository to another.
  
• Merging objects added to local repositories by application testers into the shared object repositories of the automation infrastructure, and merging two or more existing repositories.
  

Creating a Function Library

The tasks involved in creating a function library for the test automation infrastructure can include:

• Determining which keywords are needed.
  
• Creating and editing function library files in the QuickTest Function Library window.
  
• Creating the actual functions within the function libraries. You can do this manually, or you can use the Function Definition Generator to generate function definitions and header information.
  
• Defining functions as new or replacement methods for test objects. Debugging the function libraries.
  

Note: Although not directly associated with the keyword-driven methodology, the automation experts who maintain the object repositories and function libraries also often maintain a set of recovery scenarios that all application testers can associate with their tests.

Deciding When to Use the Keyword-Driven Methodology

You can create the steps in your tests using the keyword-driven methodology, recording, or a combination of both. Recording can be useful in the following situations:

• Recording is useful for novice QuickTest users. It helps you to learn how QuickTest interprets the operations you perform on your application and how it converts them to QuickTest objects and built-in operations.
  
• For the same reasons as described above, recording is also useful for more advanced QuickTest users when working with a new application or major new features of an existing application. It 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 and does not require long-term maintenance. 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.
  

• Similarly, 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.
  

Labels: QTP