I’m currently working on a large BPM project at work which uses the Global 360 BPM tool-set called Process 360. Just to give some background; this product works like a lot of other BPM solutions in that you design multiple “process maps” which define the flow of a particular business process you’re trying to model, and each process map consists of multiple task nodes connected together which perform particular functions (calling web-services etc).
Currently we’re experiencing some pretty serious issues during QA phases of our releases because there isn’t any way provided by the tool-set to automate testing of the process map routes. So when a large and complex process is developed and handed over to our test team there are often a large number of issues which crop up. While obviously you’d expect some issues to come out of QA, I can’t help the feeling that a lot of the bugs etc could have been spotted during development if we had some sort of automated testing framework which we could use to build up a set of unit tests which proved the various routes in the process map(s).
At the moment the only real development testing that occurs is more akin to functional testing performed by the developers which is documented as a set of manual steps per test-case. The problem with this approach is that it’s very time consuming for the developers to run manually, and because of this, is also relatively prone to error. Also; because we’re usually on a pretty tight schedule, the tests are often not executed often enough to spot issues early.
As I mentioned earlier; there isn’t a way provided by the current tool-set to perform this sort of automated testing. Which actually got me thinking why? Being very new to the whole BPM scene my assumption was that this was just a feature lacking in the product, but I also wonder whether “unit testing” just isn’t done in the BPM world traditionally? Perhaps it just isn’t suited well to this sort of work?
I’d be interested to know if anyone else has ever encountered these sorts of issues, and also what – if anything – can be done to improve things.
I’ve done “unit” testing with K2.net 2003, another commercial BPM. I’d really call this integration testing, because it requires a test server and it’s relatively slow. However, it is automated.
There’s a good discussion of this in the book Professional K2 blackpearl (it applies to K2.net 2003 as well).
In order to apply it to your platform, the tool set has to have an API that permits starting process instances, obtaining work items, completing work items, etc. You write tests using any supported language (I used C#) and a testing framework (I used NUnit). If the API supports synchronous calls, this is easier to do. For each test:
Base test classes or helper methods can make this easier. You could even write a DSL for testing maps.
Essentially you want full “test coverage” of the process/map – test every decision point and insure that the correct branch is taken.