SOA Testing

I am pulling together some materials on SOA testing. (CBDI members can expect a journal article in due course, the rest of you will get a few snippets of work-in-progress here. Vendors who want to brief me on some fantastic new product in this area, or anyone else who wants to bend my ear on the subject, please get in touch soonest, or leave a comment below.)

There are four reasons why we need to talk about SOA testing.

• Complexity – networks of services may sometimes be more complex than traditional applications, and therefore may be more difficult to test thoroughly. (SOA doesn't necessarily make things more complex; but it allows people to do more complex things, and when people can they often will.)
  

• Scale – Internet-scale systems raise new challenges for volume testing. Last year, Skype crashed because the unusually high restart volumes associated with Microsoft's Patch Tuesday exposed a bug that hadn't been found in normal testing [Skype Skuppered]. These kinds of situation are practically impossible to simulate.

• Productivity – as development productivity increases, the ratio of testing effort to development effort increases unless there is equivalent innovation in testing. (This has always been a problem for software productivity tools, because the front-end innovation is more glamorous than the back-end testing.)

• Redundancy – the benefits of SOA stand or fall on the amount of regression testing that is required. This is perhaps the most important reason: if we get it wrong, the IT cost advantages of SOA might be completely blown away; but if we get it right, it can be one of the major sources of benefit.