A common problem with SOA systems is performance involving multiple Web service requests. For example, I worked with a system that needed to create a bill, so it asked for a list of all accounts then called "Create a Bill" for each. This cause a number of repetitive lookups. We refactored the code so that it called "Create BillS" and let the client keep that data in memory; this saved the system from thrashing and cut processing time by 80 percent.

David Christiansen, a project management and testing expert, points out that identifying who is responsible for testing which pieces of the SOA can be critical for success, especially during maintenance. For example, if a service provider changes its implementation, you still have to do integration testing, and the integration team may no longer exist.

Putting It All Together

It's just not possible to have enough time to test every possible input and output in a SOA system. The challenge of testing SOA is to pick the right tests — the ones that will provide the most information about the software in the smallest amount of time.

To test any service-oriented architecture, we need to test all the components in isolation, as well as the common use cases where the systems are interdependent. To have a complete strategy, we will also perform soap opera testing, exploratory testing, and large volume testing of, ideally, live data. To test these, we have to test for both the happy, use-case path and the extreme, negative, destructive path.

If you follow the advice in this article and think critically, you probably won't end up with a system that is perfect — but you might end up with one that is good enough — that is fit for use. And as it turns out, "Fitness for Use" is how the Quality Guru, Dr. Joseph M. Juran defined quality itself.

So go forth, and test!