SOA testing is much different from browser, client/server and mainframe testing.
1. In SOA testing, the services based on various technologies are used.
Hence, there is no scope for unified group testing, single project testing, single application server nor delivery through a standardized browser interface. Here the ability to bring together various components helps to bring business workflow.
In SOA, application logic is in the middle tier and operates within many other technologies. SOA testing and deployment brings compatibility challenge. Various complements can be developed in isolation, but when brought together to interact at time of deployment, they might cease to function. It poses a challenge here to identify the problem source and compatibility. It is generally considered that in SOA, as the number of connection points increases, there is an exponential increase in number of failure points.
2. Quality assurance is a critical factor in SOA application delivery.
SOA poses quality challenge not only because various technologies are used, but also because of the binding fact that in SOA application "stress points" change as various individual services are added to the workflow or changed. It is difficult to find the root causes of problems across the middle tiers of SOA application. Testing at front end gives no clue of backend. Hence it may happen that the testers out of their persistent testing efforts may find many bugs in component-level code, but it will not reveal if the application fails under other environment.
Usually, SOA uses automating unit testing ("white box" testing) and acceptance/system testing ("black box" testing). But errors can occur in component interaction. Services "wrappers," like SOAP/WSDL when used around an existing RMI object, enable interoperability. Wrappers present a common set of controls that allow legacy systems and custom components to be pulled together. But they may not map every aspect of the original component.
3. Should we use the existing components or redesign again?
"It's no surprise that the top factor for implementing SOA, which 50% of survey respondents cited, is development of new capabilities." - Aberdeen report, 2005
The purpose of implementing SOA is to enable new business capabilities. There are various factors that make the software complex, which include competition, changing business environment that led to new benchmarks, business rules and logic into business systems.
Quality is constrained by time and budget, thereby limiting scope of functionality. As the scope expands, the business must prioritize functionality, so that the projects may not fall in the expected order.
SOA – Testing of Multiple Technologies
Certain components in SOA like data feed which supply relatively unchanging piece of information to the business workflow are not worth time and effort. Testing SOA requires multiple technologies know-how and testing approaches. Web services (WSDL/SOAP) are critical for many SOAs, but testing web services does not mean testing the entire technologies which make up the application.
Future of Web Services
SOA brings several implementation advantages but there are various challenges to ensure quality like continuous monitoring of work-in-progress, handling heterogeneous components, handling multiple teams or partners, and delivery to multiple parties. There are time conflicts, because of extensive use of manual testing. To overcome this the use of automatic testing for middle-tier is suggestive.
Many of the benefits of SOA become challenges to testing an SOA application. The post-SOA technologies offer vast array of assembling and workflow design options.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
