Quality assurance for SOA requires a different mindset

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.

Topics: Software Development, Browser, Enterprise Software, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • SOA or ESB - the lines are blurred

    While I agree that SOA does require a different mindset to QA, I don?t necessarily agree it's more complex than or as dismal as this article suggest. It's just different - and if done right, can bring enormous velocity to the development and QA process.

    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

      Interesting thoughts entrican but to really understand them can you describe how you define "SOA?" Can you list the SOA principles you refer to? At what level of architecture do you apply those SOA principles?

      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

    Wayne makes some great points and that is a very comprehensive checklist. He touches on service emulation, but in my opinion that is a key tenet that needs further description. And it is not just emulation of services, but any element of an end to end transaction. It may be EJB, JDBC, etc without a service interface. And it may be necessary to provide complex logic in the emulated service, such as timely data values. For more on what I mean, refer to www.itko.com/sov