Business Process Testing part 2

Continuing from where i left on Business Process Testing in my last post. I have given a brief introduction to BPT on HP ALM in my last post. 

In this post, We will look into some benefits of BPT and how does BPT works. The images in the post are the courtesy of the document provided by HP when they have introduced. I found this image as the self explanatory instead of creating anything new to confuse the users.

      The operations performed by any particular keyword tended to be very fine-grained or atomic. Designing a test for an entire business process required the use of hundreds of individual keywords — a time-consuming process.

      Since test framework solutions consist of files with keywords and their associated data elements, subject matter experts found that they were still creating scripts, despite promises by some vendors of “script less” test design.

      Traditional test framework products were not always backwards compatible with previous-generation technology — such as recorders — limiting their flexibility. With some framework products, engineers couldn’t get under the hood and modify the code that was underlying the keywords even if they wanted to.

      Test frameworks and keyword-based products still didn’t function at the business process level, forcing subject matter experts to think like programmers, which constrained adoption rates.

      Test frameworks did not assist in the creation of test documentation, and therefore required the investment of many man-hours to create the detailed information required for compliance with several of today’s legislative acts regulating data access. 

How BPT works:

To create an entire business process test, the subject matter expert simply selects the desired component from a tree-structured list (like the File Manager in Microsoft Windows), then drags and drops the components into the Mercury Business Process Testing Workspace. For example, the Log On component could be the first step of a business process for placing any order. Other components might include: Find the product; Search the product; Place Order; View Open Orders; Confirm Order; and Log Out.

Prior to execution, components are eventually implemented by subject matter experts using keywords, or by QA engineers using the recorder and script commands. But the implementation of the components is separated from their design and use in creating scripts, so the subject matter experts can focus on the business processes.

I will continue in my next post with the some descriptions on the components required for BPT and gets developed in UFT for e.g. application area, business component.