Over the last couple of projects, I have been trying to establish a
set of methodologies around initiation, development, deployment and
management of business processes using Oracle BPM Suite 11g. In a series
of posts, I will be taking about a lot of problem areas that can be
effectively tackled in order to deliver a highly successful BPM project
using this technology.
The areas I intend to cover are around
design and modelling best practices, team development, delivery
methodologies, testing, troubleshooting, automation, performance tuning
and operational management to name a few. However in terms of priority
and the nature of pain experienced in each of these aforementioned
areas, I am of the opinion that a great chunk is attributed to testing
and maintaining code quality. Business processes are in constant need to
be truly dynamic more than ever so that planned as well as ad-hoc
changes can be promoted seamlessly. Also with Oracle BPM Suite 11g
promising greater involvement of business users in terms of making
deployable changes to the processes, ensuring that functionality and
quality of the build/changes is maintained is very crucial. In the
previous blog post, I had elaborated on unit testing strategies for
business processes and methods of achieving them from the Oracle BPM
Suite 11g studio. Proper unit testing is important in terms of
validating that the core logical outcomes of a business processes are
executed as expected. This ensures that all sequence flows and paths in a
business process are tested and conformant. The post can be accessed here.
apart from testing the basic process paths a lot of other things demand
testing too. Business processes can populate data in downstream
systems, integrate with services, create events, send notifications,
assign workflow tasks which may have their own lifecycle, etc. From a
quality perspective all of these steps must be verified too. The overall
functionality of the business processes must be thoroughly tested to
determine their reliability before being deployed to the actual IT
infrastructures. Organizations do invest in quality measures to evaluate
features of business processes by employing a comprehensive testing
strategy, involving analysts, developers, functional testers and
business users. However they begin to invest in test automation very
late in the project lifecycle. This poses a significant threat and
concern, particularly when the business processes are continuously
changing and evolving. An increasing pace of business process changes as
well as applications growing more complex means that many functional
testing teams are reaching the breaking point. Change management becomes
difficult as there is always a risk of introducing new bugs down the
way. As much as we all would like to have agility, the process is
defeated by having improper developer operations.
regression functional testing suite very early in BPM project
development cycle is, by my opinion a must have thing for any successful
and timely implementation. More often than not, it is not the choice of
technology that is responsible for this but rather the lack of some
Typical Problem Areas and how Automating Functional Testing can help
my interactions with different project teams, here are some typical
questions they have, especially with respect to testing business
processes in Oracle BPM Suite 11g.
- Is it possible to really
approach functional testing early in the project cycle considering the
nature of composite applications involved (business processes, services,
- Human tasks components in business processes need
to have user interfaces (which may have their own development
lifecycle). How can functional testing be achieved before a fully
- Are their any developer tools, approaches or frameworks that can be utilized to automate functional testing?
kind of a functional testing strategy is suitable, cost efficient and
good to contain a wide variety of problems in the project lifecycle?
we begin to investigate the possibilities, they may be endless. I, am
particularly aware of many custom products which promises to take care
of all of these. However hey tend to be expensive, have a steep learning
curve and may not always fit the bill. This act as a big deterrent.
However, in this article, I am keen on presenting an approach that is
quick, easy, developer friendly and can be easily catered in the
development phase of the project. The best way to begin with functional
testing is to base it on the business process design. Model driven
functional testing ensures that critical processes and their paths are
covered and that any variation of those tests can easily be amended and
rerun without adding to significant time to the test cycle. Functional
testing can start earlier and better quality tests are produced and
maintained in a test repository. This can then be part of the continuous
build and integration iterations to ensure sufficient test coverage in
accelerated delivery cycles. A part of model driven testing strategy was
described in details with respect to ascertaining the cyclomatic
complexity factor of the business processes and deriving test cases
based on that. This approach is a very good starting point, especially
because this can be used to build unit tests too. Once the basic process
paths are determined, the functional test suites can incorporate a lot
of test steps to cover the functional aspects such as validate business
logic and rules, verify data across systems, check events and
With all this being said, however, automation
of functional testing will only be successful if an organization’s
underlying quality fundamentals are solid and everyone clearly
understands how testing can continuously support process iterations.
Another big advantage to automate early is potential time savings.
Considering that multiple stakeholders will need to repeat their testing
task, every time something changes, doing them manually becomes a
burden sooner or later. Have a look at the sheet I’ve compiled based on
various time and frequency of performing functional tests and the effort
involved in each case.
The columns marked in green
in the above sheet reflects the most likely scenarios in terms of the
amount of time spent on testing in various Oracle BPM Suite 11g
projects. The effort involved in manual testing can range from 20 days
to 4 months for a very simple and less frequently changing business
process to a complex and often changing business process. This effort
does not accounts for test planning but simply reflect the time spent in
test execution. The columns in red represents scenarios that can be
applicable for certain project types too and in those cases the amount
of time spent in manual testing can be even 8 months. This offcourse is
under the assumption that all quality standards of software functional
testing are maintained.
Approach and Tooling
indicated before, there are many players in this field providing varied
approaches and option. This article will not debate their merits here.
In the course of my involvement with BPM projects, I seems to incline
towards SOAPUI. This is particularly due to the fact
that it is pretty inexpensive (there is also a freeware if ~$350 license
cost seems significant) and does most of the basic functional testing
that can be considered acceptable from a quality perspective. It is
fairly straight forward too and the learning curve is minimal. Chances
are also high that in most projects there will be developers with
considerable amount of experience using SOAPUI, if they have been
involved in a SOA project in the past.
Having said that, this
article will talk about how to plan and implement a comprehensive and
automated functional testing suite for business processes developed
using Oracle BPM Suite 11g. Read the full article here.
SOA & BPM Partner Community
regular information on Oracle SOA Suite become a member in the SOA
& BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog Twitter LinkedIn Facebook Wiki Mix Forum