After years of not being sure, I have recently decided that it is in fact possible to do (and I mean really do) automated testing for IBM BPM. I still haven’t seen it done properly but, I am working on it…

It’s a big topic so it will span a few blogs (probably five) but this one will outline how (I think) you should do it.

1. Our process application has one process. It is called Request Something and it allows Employees to Request (e.g. new hardware or software). Requests are Reviewed by Managers and Provisioned by Operations.

2. In the request activity, employees can select one or more items of hardware and provide a text justification for the request. In the review and provision activities the users can review the request, add comments and take actions.

3. A list of hardware is retrieved via a Web Service.

4. A Service is used to determine if it is necessary for a manager to approve a request.

The good news is that there are a bunch of great tools and technologies for automated testing. The not-so-good news is that IBM BPM needs some persuasion to work with these tools and technologies.

I will go into more detail in the subsequent blogs but, to make this work, you are going to need to:

I have tried (more than once) to do automated testing without these things and I found that the coverage, reliability and effort required were all unsatisfactory.

So here is the “meat on the bones" for this introductory blog: you should be creating four types of test script to give you complete (and effective) test coverage:

1. Process Flow Testing

I will go into this in more detail in a future blog but in here you should be using the REST API to validate that your process diagrams are correct and that, for given data, they behave the way your expect them to. In my example above one test might be to check that a rejected request is not sent for provisioning.

2. Activity / UI Testing

I will go into this in more detail in a future blog but in here you should be checking all aspects of the user experience. The primary focus is on the activities (in isolation) and that the UI behaves the way that you expect it to. In my example above one test might be to check that the employee is not able to submit a request without selecting something to request.

3. Integration Testing

I will go into this in more detail in a future blog but in here you should be making sure that your integration services are working. It’s not your job to test the systems you are integrated with but, if you application makes assumptions about the data that is returned, you should check that those assumptions are correct. In my example above one test might be to check that a list of items to request is being returned by the external system.

4. Service Testing

I will go into this in more detail in a future blog but in here you should be executing input/output-style unit tests against the Services you have created in IBM BPM. In my example above one test might be to check that the automated approval logic works as expected for a number of different example inputs.

I have tried my best to avoid mentioning technologies but I imagine that any reader taking inspiration from this post will want these details. Here is a list of tools and technologies (with some supporting comments) that I am currently using:

Gherkin / Cucumber (people have mixed opinions about this one but I like it)

Java

Selenium (you don’t have any real alternative but use it sparingly and only for Activity / UI Testing)

REST Assured (this is my new favourite thing, it’s awesome)

There is a time and place for manual testing. In fact there are two:

The first is for exploratory testing (where you get people with very specific character traits to mess around with you application and try to break it or make it do something weird).

The second is for acceptance testing (where you allow real users to have a go in a non-production environment).