| Title: |
SOA Testing: Managing Testing in an SOA Environment |
| Author: |
Richard Veryard |
| Publication Date: |
30 April 2008 |
| Report Type: |
Journal |
| Report Class: |
Best Practice |
| Abstract: |
SOA represents a paradigm shift in the way solutions are architected and delivered. The service is a run time artifact and may be surfaced as a component, either as the run time invocable capability, and or as the design time component. Either way SOA is inherently about separation and this creates potential opportunities in the area of testing. In this report we consider what impacts SOA can have on testing, and what impact testing may have on SOA. |
| Backgrounder: |
There are five reasons why we need to talk about SOA testing.
Complexity: networks of services may be more complex than traditional applications, and therefore may be more difficult to test thoroughly.
Scale: Internet-scale systems raise new challenges for volume testing.
Productivity: as development productivity increases, the ratio of testing effort to development effort increases unless there is equivalent innovation in testing.
Decoupling: the more layers of abstraction you have, the more complex it is to verify that all of these layers will work together when you hook them up, and the harder it can be to validate behaviors at other layers that may affect the one you are testing
Componentization - the benefits of SOA stand or fall on the amount of regression testing that is required. The elimination of redundant testing is perhaps the most important reason why we need to talk about SOA testing: if we get it wrong, the cost advantages of SOA might be completely blown away; but if we get it right, it can be one of the major sources of benefit |
| Report Size: |
17 pages |
| Report Access Type: |
 | Silver/Gold (Premium) |
|
| Available for separate purchase |
Single copies of recent CBDI Journals may be purchased |
| Login |
|
Home