SOA Testing

Recently, we've been working on our SOA testing methodology. As many of you know, testing becomes more complicated in any environment that has lots of shared resources (like SOA) and where they resources may be changed/versioned.

I recently had an interaction with Wayne Ariola at Parasoft, where he offered the following advice:

The key points from my point of view:

1) From a quality point of view the test driven process requires a SOA Aware testing framework. This means that the framework must be aware of the intermediary rich environment as well as the distributed nature elements required for the overall business process.

2) As the title of the presentation suggests, the onus of quality resides with development. Ensuring that new versions conform to published interfaces cannot be a QA function - in fact development must take an additional step to understand the impact of the change versus the regression suites as well as the overall business process. This business service orientation and the iteration/evolution of services will not be as convenient for QA to test as they are used to in an application centric environment.

3) Connection to the code. This is the big bang! Development must not only ensure that the service version is robust but must also tie the message layer changes to suite of code level regression tests.

The Parasoft SOA Quality Solution is built on an SOA Aware test framework that allows the user to exercise the message layer for security, reliability, performance and compliance as well as drive code level component tests from the message layer by automatically creating Junit test cases.

This got me thinking - what are the Golden Rules of SOA testing? Well, I think I've got my list which I intend to share at the Infoworld SOA event next week. Should be fun!