The marketing guys are at it again - read David Thompson's recent discussion on SOA Testing.
Actually, we are very glad this discourse is happening out there. SOA Testing has long been relegated to a project milestone somewhere after development and integration happens. Our CMO Jim Mackay just had to chime in. SOA Testing is a continuous part of SOA Governance, and not an event that unit tests a specific technology as a pre-release feelgood.
True, you do need to test the Web Services (if that is a part of your SOA approach) to be compliant to WS-I, etc. And of course, you need to be able to test the Messaging layers for compliance with the platform as transactions move through the architecture. But these kinds of tests don't tell you if the business requirement is being missed. Or if the upstream and downstream dependencies are creating problems.
You also need to test the database, and the front-end HTTP. And the EJB itself. And both the legacy CORBA objects and the new POJOs sitting at the implementation layer. If SOA is making that round trip, your testing should make the round trip as well.
And testing should support the entire extended set of players collaborating on SOA, from the people writing the requirements, to the developers implementing them in SOA, and the QA teams verifying the functionality and performance.
And SOA testing should be continuous, not just in development and integration, but in deployment, because an SOA by nature is never a static application.
Remember the old School House Rock educational commercials? "I'm just a bill, yes I'm only a bill, and I'm sittin' here on Capitol Hill..." Well, the humble Test is just like that bill waiting to become a law (or an SOA Policy). In order to get there, it is going to need the support and nurturing of the SOA community at a company level, and at large.
In other words, we promote the humble test as a actionable aspect of the vaunted concept of SOA Governance. To be part of Governance, the SOA Test must contribute more than a specific technology checkpoint at a specific point in time. A test must span the SOA application, continuously, and in so doing, it becomes a verifiable SOA Policy.
More on this concept to follow - and your thoughts welcomed.
Comments