Adjusting for SOA Testing

SD Times recently published a good article by David S. Linthicum: Adjusting for SOA Testing. David argues that for SOA Testing, existing testing techniques and tools should not be tossed out but we need to rethink the concepts and technology behind SOA and "adjust" accordingly.

Depending on how much "adjustment" equates to a total toss out, perspectives may vary. We believe that adjusting the technology by slapping on service-orientation to testing products that were grounded in web-site testing is a severe adjustment.

How services are tested, require a clean, ground-up testing product that is built for testing services, their dependencies and re-use rather than testing web sites. The primary focus of SOA is re-use and testing tools focused on SOA need to be built with testing re-usable services in mind.

We humbly differ from David that adjusting the technology is sufficient. Tossing out web-site testing tools and adopting a SOA Testing Tool built ground-up for service testing is a better strategy that saves hours of test suite authoring for functional, performance, interoperability and vulnerability testing.

We do agree that the testing techniques need to be adjusted. One area of emphasis within SOA Testing is abstraction. Most likely, a modern SOA is built using web services with access to only a WSDL file and not the actual source code. This eliminates the ability to do White Box testing and restricts users to Blackbox or Gray Box testing. See for example: SOA Testing Tools for Black, White and Gray Box Testing.

Overall, David does a great job in bringing this discussion to everyones forethought - if quality and security are not addressed with a SOA deployment, the reuse of poor services are bound to proliferate and degrade the overall quality of a SOA.