Over a period of many years, object-oriented computing profoundly changed many aspects of software development. Why should SOA be any different? SOA takes notions of objects to a higher level of abstraction. It frees services from the bounds of a single-system view. In turn, it places greater emphasis on communications and the integration layer. As a result, testing and performance change greatly when a corporation moves to SOA.
With SOA, the integration layer becomes much more of a "gray box" for development and test teams. The gray box lets you inspect some of it properties but leaves others veiled. It is new territory to many team members who are more familiar with the either/or nature of more traditional white box and black box testing.
The history of SOA has been one of highs and lows. SOA started out with great fanfare -- too much, really. This was followed by wide disappointment, as SOA implementers went to work and failed in many cases. It wasn't too uncommon to approach a SOA project with over confidence, underestimating how much organizational change was required, especially on the test end of things.
Some enterprises have responded by building not just a Center of SOA Excellence but also a Center SOA Test Excellence. It can be daunting to uncover best SOA test practices. Setting up a useful SOA test practice will be important, but setting up a formal center is not for everyone. Nevertheless, managers will need to find team members with the right skills; they will need to go about adopting a SOA test practice framework.
Bit by bit, and many years now into the SOA experience, there are signs of endorsement and success of SOA that is at least on par with its predecessor software styles. Among the lessons learned: SOA test is different. It requires its own type of test architecture and tester skills. It has taken the best of firms several years to really figure out the best SOA test practices. But such stories are going to be more widely heard in months to come.