A glance at HP’s QC11 ‘ALM’ - BPT module

For those short on time the most significant material is in black. 

 

Elaborated this becomes Hewlett Packard’s Quality Centre eleven ‘Application Lifecycle Management’ Business Process Testing module.

 

A few days ago I was asked whether I knew what BPT was, sadly all Google could refer me to were HP sales docs or inane forum posts. This is intended to be as fast an overview as possible of what QC’s BPT is with mini-delves in to relevant areas. So, let's take a quick look at our surroundings:

Core Test Objectives

1. As a business I want requirements to be verified.
2. As a business I want the cost of script creation and script maintenance to be as low as possible.

HP’s QC has always achieved (1) but can struggle on (2) without super-stringent process adherence. BPT makes (2) a bit more structured and a bit easier to achieve.

A breakdown of the core BPT-relevant concepts in QC

• Requirements
• Tests
• Manual Test Script / steps to verify something
• Reusable Template / reusable steps to perform some action
• Business Component / think of this as a reusable test script
• Business Flow / think of this as another reusable test script
• Business Process / think of this as the test scripts cello taped together to verify something
• Test run
• Pass/fail...

The process to date sans BPT has typically been (a) make requirements > (b) make tests for requirements > (c) run the tests. The addition of BPT essentially is a replacement of (b).

Business Process Testing is a fast and efficient way of creating, organizing and executing tests. It is extremely similar to using manual reusable templates to build up a script, but it extends the idea by pairing seamlessly with automation, and including an easy, user friendly interface for building up tests.

The beauty of it is that your test set becomes like Lego. A few engineers make the bricks and then anyone can effortlessly create the tests. And I genuinely mean anyone: testers, business analysts, managers.

As with all of these things, simply simplifying an activity makes it easier to adopt, easier to follow, and reduces user error along the way.

 

New workflow

Create requirements > create business processes (replacing test scripts) > create relevant business components (the Lego to make the business process complete) > run the thing

Exciting part

Okay, so my background is automation and this part made me giddy with excitement. The business components (Lego blocks) can be automated using QTP, and in doing so work seamlessly within QC.

 

This means a person who wants a test for something but doesn’t understand automation can come along, throw the blocks together, and voila, they have created a new test. Going further, if they then press a little green button their test will execute immediately. It is an automated test thrown together in no time. Done. QED, in fact. *

*It is important to note that in no way should this be misconstrued to undermine the great deal of work which is needed in automating the business components in the first place; the individual components will take longer to automate than a normal test script because they must be so modular and robust. And not to forget that they will need to be maintained.

Overview

Pros

• Test-creation extremely efficient
• Test-maintenance extremely efficient
• Anyone can create tests

Cons

• Anyone can create tests
• Some granularity might become cumbersome, or just get lost - would this be overkill for a thorough function test of a new UI feature?

Moots

• Still need to be clever about how data is stored
• Still need to be clever about how testing is done

 

Further research required

• Is it really wise to have verification steps stored in a reusable document / what’s the best practise to ensure that they are never accidentally deleted resulting in a false pass
• Does this get confusing with multiple data-dependencies between all of the Lego blocks / how can this be managed
• Does this merely compliment or actually replace the need for ‘test scripts’ in QC