Quality assurance in Service Oriented Architecture (SOA) is necessarily more complex than conventional software. Due to the concept coined by Vinoski (2008) as serendipities reuse, most SOA developers must plan, by default, for unknown uses of their software in future cases. Testing can be done with regards to service load and intended functionality, but for an SOA component to find wider use, it is necessary to plan for flexibility from the outset.

In addition to planning for unintended use, a common thread in SOA Quality literature is the need for continuous regression testing (Memca, 2006; Ariola, 2007). Essentially, it is necessary to develop test cases for business logic, and to run them continuously as new code is added. This can prevent the unintended “breakage” of code by the introduction of a new piece of logic.

Quality assurance is becoming a more significant part of the developer’s job, as testers expect to spend more time examining business process logic and less time chasing software bugs (Ariola, 2007).

Personally, I see SOA quality assurance as a sort of magnification of typical Object-Oriented quality assurance. Many of the same tools and paradigms are useful, from continuous regression to patterns analysis. However, in SOA, the problems can become magnified by the use of the software in un-planned packages or business applications.

References

Ariola, W. (2007). SOA Quality Assurance. EBiz. Retrieved February 25, 2009, from http://www.ebizq.net/topics/soa/features/8347.html?page=2

Memca, A. (2006). SOA Quality Assurance. IT Toolbox. Retrieved February 25, 2009, from http://it.toolbox.com/blogs/anewday/soa-quality-assurance-11150

Vinoski, S. (January 2008). Serendipitous Reuse. Toward Integration.