Quality assurance for SOA requires a different mindset
Summary: Quality assurance assures more trust in SOA -- and SOAs depend on trust
Forget QA as you knew it -- as it seems to do with everything else, SOA upsets the apple cart.
Quality assurance assures more trust in SOA -- and SOAs need trust
SOA has a lot of moving parts, so more traditional QA processes -- in which software is developed, tested, and handed off to a QA team for more testing in a very serialized manner -- will not work. "Given the distributed and complex nature of SOA, it is virtually impossible to 'stage' an SOA environment," says Wayne Ariola, VP of Parasoft.
In a new article, Wayne compares the QA process for SOA to that of embedded systems. He points out QA in the SOA world requires what he calls a "process cadence" that "initiates the quality process as soon as services are defined," based on a collaborative and building-block approach.
Wayne makes the following recommendations:
- Promote visibility. SOA is all about trust. The enterprise needs to be confident that all parts of the SOA are in working order. "Visibility will ultimately promote trust," Wayne says. "Trust will ultimately promote reuse of these business assets."
- Supply an automated infrastructure for reuse of testing assets. Just as SOA is about providing reusable services to the rest of the enterprise, testing artifacts should also be "reusable." As Wayne explains, "You do not want people redoing, recreating and rerunning the same tests over and over again. You want to make sure that test assets are created, shared, leveraged and extended properly among team members in order to achieve maximum efficiency." An automated infrastructure for storing testing assets -- such as a repository -- can help accomplish this goal.
- Promote bottom-up quality. QA needs to extend beyond the service and messaging layer to the underlying applications. Wayne urges the efficient application of coding standards, static analysis and unit testing to underlying assets -- and make this transparent to the rest of the enterprise as well.
- Leverage top-down quality as well. Wayne advises plenty of attention to the messaging layer as well -- including activities such as verifying WSDLs and BPEL files, as well as building security best practices into the software development lifecycle.
- Emulate as much as possible. Complex SOAs stretch to endpoints across the spectrum, including service customers inside and outside the enterprise, which cannot be tested directly. Such an extensive environment needs to be emulated.
- Improve, improve, improve. As with all QA processes, continuous improvement is the name of the game. Keep on measuring and tracking, Wayne advises.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
SOA or ESB - the lines are blurred
I believe the lines between SOA and ESB (Enterprise Service Bus) have been blurred a bit based on some of the dialog in this article. An ESB does make certain assumptions about disparate enterprises services working as advertised, but that?s not a core tenet of SOA. Services can exist within the ESB fabric and sill not be built on SOA principles. SOA is all too often cast in the Web Services view of things which is how many ESB application components come to exist when they weren?t originally developed with SOA principles.
In short, SOA promotes a highly messaging centric approach to creating software. A discrete business function requires certain inputs and will produce specific outputs. In many ways, this model simplifies the QA process by allowing for easier automated tests against defined messaging structures leaving the more complex tests such as scenario based to humans and functional experts of the system.
Define SOA
Service orientation prescribes nothing in terms of how services interact--thus it would seem inaccurate to state "SOA promotes a highly messaging centric approach." An SO implementation might use messaging as the communication vehicle but that's a technical implementation decision, not an architectural requirement.
But, that's why I'm asking how you define "SOA."
RE: Quality assurance for SOA requires a different mindset