Web Services testing not necessarily SOA testing

I believe we need to say this as often as possible, because there are still people out there equating web services testing to SOA testing. I think this is a dangerous assumption that will create a false sense of security if you lean on it! Story here: http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1215776,00.html?track=NL-110&ad=564937&asrc=EM_NLN_540509&uid=4955522 Jason's take:

Indeed SOA is changing testing, and web services testing is a part of that. Web services are often the first toe-in-the-water for an SOA strategy, but we must remain vigilant of the fact that they are just one possible component of the typical SOA.

The most significant quality issues companies will face as they migrate to SOA will be the fact that web services make applications easier to deploy, but harder to test. If you look at the input and output of a web service itself, you see only the XML that the service provides, and not what is happening within underlying technologies.

Any serious enterprise relies on an alphabet soup of middle tier technologies: from legacy and mainframe components, to databases, messaging layers, Java, CORBA, .NET and more. Further obfuscating the quality issue is the fact that few of these components will be built from scratch by any one team of developers. Each service your SOA touches is on its own lifecycle, and may be managed by distributed teams outside your department or company. SOA makes unit testing less relevant than continuous integration testing, because one team seldom manages every service in the architecture.

On the organizational side, of course, every consultant's main job is to seek and destroy siloes, wherever they may be. Breaking down the walls between development, QA and business analyst organizations is a good thing. The best case scenario would be to have "pair programmer/QA" units working together to test components, and the later integration points both early in development and throughout deployment to ensure that business requirements are met. To get there, QA individuals will have to become more technically savvy if they are to test technologies that can interact without a user interface. Developers will have to give as well, by test-enabling their developed components for QA and business teams, so they can be taught to "play nice" with other services to flexibly form business processes.