Software Quality in an SOA World

February 26, 2006

Software Quality in an SOA World

Software Quality in an SOA World
by Judith Hurwitz

Software quality has typically been viewed as the task of the QA group within the IT department.  In many of these organizations, testing is not necessarily high on the radar screen of senior business or IT management.  Hurwitz & Associates believes that this will begin to change dramatically with the movement towards a Service Oriented Architecture (SOA).  However, today, few organizations have made the leap from their traditional approach to software testing and the world of SOA.  Most testing organizations today take a bottoms-up approach to testing.  Many still rely on manual and acceptance testing.  They assume that if they have business users put the application through its paces they have done their job.  Other companies rely on their own homegrown testing tools to ensure quality.   While in many traditional applications this may meet many quality requirements, these approaches will fail in the SOA world. 

If one considers the differences between a traditional application and a SOA-based application, the issue becomes clear.  A traditional application is typically build to execute one business function (i.e., processing claims; bill paying; customer self-service).  These applications are written so that all of the parts are written as an integrated whole.  Therefore, testing at the functional, load, or performance level makes sense.  If an application has been around for a while, it may be sufficient to have business users perform acceptance testing to make sure that the navigation is correct and that there are no unanticipated glitches.

In an SOA-based application, there is no real notion of that one function application.  Rather, an SOA application is a business application designed from a set of business services that are linked together through web services interfaces.  The nature of SOA implies that the same components are used in many instances throughout an organization. They have to work. They are by definition critical to the organization. Customers will be able to create composite applications based on business requirements.  In some cases, customers will use web services to call outside services from a third party.  Conventional approaches will not ensure that each business service is free of outside dependencies.  These approaches will also not be able to perform true integration testing.  This type of integration testing is different than those used in conventional circumstances.  This type of integration testing requires that organizations be able to test a composite application assuming that links between services are not permanent.  Organizations must also be able to test the security of these composite environments under a variety of scenarios.

Simply put, manual or ad hoc tools will not be able to support the sophistication required in the SOA world. Much the same can be said for testing tools designed to support the testing of conventional applications. 

If your organization has begun to think about building SOA applications, there are some fundamental issues you consider for planning your SOA quality strategy.  While the overall list will be long, the following five principals are at the heart of beginning to think differently about software quality:

1. SOA testing has to begin with a top down approach.  First understand how you plan to bring business services together to solve specific business situations.  Plan for SOA Integration testing as the number one priority.
2. Understand what you are testing for.  For example, you will be testing for the presence of dependencies in a business service.  You will also test for the viability of web services interfaces.  You will also need to test the overall security resulting when you combine services.
3. Most companies think first about load testing, functional testing, and performance testing.  Obviously, these remain important but they must be viewed differently.  These testing approaches will be viewed at the component level rather than at the application level.
4. With SOA, it is imperative to start with a well thought out set of business and technical requirements that you will test against.  Without this type of discipline, SOA testing will fail.
5. Putting all the focus on business acceptance testing will lead to failure.  Having business users ?sign off? on acceptance testing will only ensure that one instance of the composite application works. It will not protect the organization from failure.

 

Newsletters 2006
About Judith Hurwitz

Judith Hurwitz is an author, speaker and business technology consultant with decades of experience.

Leave a Reply

Your email address will not be published.