Is Automated Testing the Answer?

  • November 19, 2018
  • Joe

Editors Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse based designer to IBM Digital Process Automation’s Web Process Designer. To start your readiness check register for our questionnaire here:

Is automated testing the answer to resolving problems with:

Toolkit Dependency Management
In-flight instance migration

in your IBM Business Process Manager (BPM) environment. Yes, actually, it is!

But, I hear some of you asking, isn’t automated testing in IBM BPM incredibly difficult? Well, perhaps surprisingly, no it isn’t. However, there are no standards for automated testing in IBM BPM so what you tend to find is that each customer has a bespoke approach to the problem. So, whilst it isn’t necessarily all that difficult it can be expensive since you largely have to start from ground zero.

As well as the lack of any standardised approach to automated testing in IBM BPM, cost is another reason common that many customers have not implemented it. Yet another reason is that due to the nature of the fact that BPM is quite business-oriented. This very often results in either the business owning the software or, at least, providing sponsorship and/or leadership regarding its development. In these situations the programme leadership team may simply not have the technical insight that would lead them to drive the team to adopt automated testing in the same way that a programme manager drawn from the IT function in the business would.

BP3’s automated test tool – Brazos Tester – has been introduced to address this lack of standardisation in IBM BPM testing and to save customers the time and effort of developing a bespoke approach to automated testing. Since it provides the framework for executing automated tests it is only a matter of developers writing the tests that need to be run – and it has helpers that can reduce the time to do even that.

The approach I would take is as follows

● Build Toolkit Dependency hierarchy
● Starting from the bottom, build automated tests for each Toolkit and take snapshot
● Finally take new snapshot of each Process Application and re-deploy

You won’t be able to do this all in one go. So, take your time to plan the work and fit it in with your existing development and release cycles as far as you can. And don’t forget, the sooner you get started the sooner you arrive at your destination of faster releases with more reliability.

Related Posts
  • August 27, 2019
  • Scott

Camunda continues to advance the state of the art for distributed workflow with the first production release o...

  • April 16, 2019
  • Lance

If you have been thinking about automation or performing small pilots, now is the time to get very serious abo...

  • April 6, 2019
  • Scott

Pre-amble.  A couple of weeks ago I attended the IBM Think conference in San Francisco. It was the first ti...