An Introduction to Mercury Business Process Testing

To add more value to this blog from now on I have started posting original articles from my friends.

Author: Shuchita Dwivedi (ISQTB certified, currently working as Test Analyst with Travelex)

Till now the buzzword in software testing arena was “automation frameworks”. Frameworks enable keyword driven testing where subject-matter experts like analysts or management users can design test cases using pre-defined keywords (keywords implemented a specific action). This was an attempt to automate testing process without the need to write scripts that needed specific programming knowledge. Though this approach improved testing activities for many teams, there were some inherent limitations with this technique.

  • Each keyword had to be ‘atomic’ in the sense it represented the lowest level independent module so that its reuse in other bigger modules could be facilitated without the need to modify it.

  • Subject matter experts still had to write scripts that involved keywords and data-values associated with them.

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

Mercury came up with their tool – Business Process Testing. Here subject matter experts work with various modules. These modules are called ‘Components’. For e.g. to issue a book, if user first needs to logon, then ‘LogOn’ component would be available that can be included in the test-case as the first component. Next component may be ‘IsBookAvailable’, next may be ‘IssueBook’ and then ‘LogOut’.

From a library of components, analysts just drag and drop those components that are needed to design or complete a specific business process or test-case. Subject matter experts only need to concentrate on high level components; using them they complete their test-cases. Implementation of these components is then passed on to testers. So there is a clear demarcation of ‘design’ and ‘implementation’. Once all the components within a process have been coded by testers, that specific test-case is ready for execution.

This has the benefit of reusability – if a component is needed by any other process, it can be just imported into that process or test-case.
Another major advantage is integration of test automation and documentation. While the tests are being created, the tool creates detailed test records that can be exported into simple to-access word processor formats, like MS-Word etc. Test records describe every business process, all steps taken, all data used to certify the process, every data element used, and the results of each action taken.
Now let me summarize the key benefits and features of Mercury Business Process Testing tool :

  1. Subject Matter experts can build tests by simple drag n drop facility.

  2. Time involved in test design, scripting and documentation is reduced to a great extent.

  3. Component re-usability.


  1. Prasad9:28 AM

    Shuchita, Good article, Very informative, keep posting such articles.

  2. Malik,

    I would take the concept of BPT with a pinch of salt. Though I have not fully explored tool feature - the way it is being projected and marketed makes me to ask few questions....

    1. Any serious Automation is software development. Hence all the attempts to "reduce" automation as a job of a non technical and non programmer are indeed not "really" True.

    2. The words like "re-usable", "drag and drop", "easy to use" etc are marketing jargons. They look well in product demos, and sales pitches. In real automation projects - you really know what all they mean. To understand the pains of automation, one has to run 1-2 years of automation development, maintenance, deployment testing.

    3. First of all take the term Business Process Testing –

    How can a tool do the testing? What kind of testing?
    When we are talking about Business process - which application? Can a business process stand on its own without an application?
    What this all has to do with automation?

    First of all, testing process can not be automated if testing is done by human beings. When the people say "automate testing process” what they mean is "automate the execution of some set pre-determined test cases and result verification". Is this all testing? What percentage of automation we have been able to achieve in a typical project?

    In all though the concept of business users and subject matter experts doing testing looks tempting - but in a long run, we need programmers, testers and developers to maintain the code.

    I repeat here that automation is software development as final deliverable is code. Any attempt to simplify this should be viewed with suspicion.