HP QTP

Lessons from a HP Partner in Vancouver

Before I delve in, let us first take a deep breath and appreciate the implications of Testing in our daily lives! A 30 second Ikea commercial nicely summarizes the importance of quality.

 

QTP is a tool for automating functional and regression tests. QC works as a quality management platform that offers requirements management, test management, defects management, and business process testing. Together they are a powerful force which significantly facilitates functional test automation.

These are award winning products, now an integral part of the multi-billion dollar HP Software Portfolio.

This is a 2-part series. In this article, Part 1, I am going to focus on QTP and describe some best practices to automate functional tests. In Part 2, I will shift my focus to the functionality of QC.

I’m currently involved in a large automation project. These are our views based on our project experience.

Part 1: QTP

Steps & Guidelines

1. Obtain knowledge and define test scope

Step 1 is to get familiar with the application under test, test environment and manual test steps. We should consider the following areas when we acquire the knowledge of the test: test purpose, test environment, applications required, test verification, and unexpected behaviours.

With the knowledge to understand and execute the test, we will have enough information for automating the test and defining the test scope.

2. Write manual test steps

Even though the test is automated and manual testing becomes a very rare case, it is good to have clear and precise manual test steps for reference. When we write the test steps, we should assume the readers have very limited knowledge and experience of executing this test. Therefore, the steps should be very specific and detailed. For example, pressing TAB may not be documented sometimes because it seems too tedious, but it may be a very critical step to the test.

3. Divide the test steps into components

A test may consist of 20-30 test steps and require multiple applications. Since some test steps are used in lots of test cases, grouping test steps into components can exploit the reusability of the test steps. There is no strict rule for dividing the test steps into components, but each component should serve one purpose and can be reused as a standalone component in lots of tests.

4. Write test script for each business process test (BPT)

After the test steps are grouped in several business components, we can start developing test scripts.

Here are some steps for developing a script:

i. Create a shared object repository:

The object repository contains the objects used in the test. This repository can be built by simply recording the steps with QTP or using QTP Object Spy. After the objects are added to the repository, we can save this repository in the QC server, and this repository can be used among different tests.

ii. Create an application area:

Every BPT test script is associated with one application area, so we need to create a new application area with the required add-ins, an object repository, functional libraries, and recovery scenarios. The test script inherits these settings from the application area. An application area can be used by different tests, but a test can select only one application area.

iii. Develop the test script:

QTP allows users to write the test script in keyword view or expert view. If complicated logic is involved (such as if-else, while loop, randomization, etc), keyword view is not able to provide such support.

Developing the test script includes:

  • Record a simple test flow: Recording the test steps with QTP is a good starting point; in fact, do not bother too much about handling special cases, adding verifications, and so on at this stage. This phrase can identify any problems or issues with running the application with QTP. In some cases, QTP does have problems with launching and running some applications. After we know of these problems, we have to first tackle these blockers by coming up with some workarounds.
  • Add verification: There are two ways to verify data; we can either use a QTP checkpoint or use a customized checkpoint. QTP provides 8 types of checkpoints, but sometimes creating checkpoints for parameterized data is not straightforward. On the contrary, a customized checkpoint provides the flexibility to verify in different situations. Here is an example of creating a customized checkpoint:

If <Condition> Then

Reporter.ReportEvent micFail, “Login”, “Username is invalid.”

End If

  • Implement logic: Recording the test steps does not generate the important logics behind the scene; therefore, we have to implement some logics for the test by ourselves. The logic can help handling special scenarios, generating test data, verifying complicated elements, and so on.
  • Parameterize variables: In most cases, we have to parameterize variables so that the test script can be generic and accept different data. Parameterization using QC and QTP is straightforward.

5. Combine components into flows and a test

After the test scripts of the business components are complete, we can combine them into flows and/or a test in QC.

In Part 2, I’ll delve into QC and eventually tie-up all the pieces together to expand on how the combination of QC & QTP fits into the overall strategy.

For more details, please feel to connect with me at Maggie.yu@optimusinfo.com