Key Steps of SOA Testing

The following are the steps that need to be performed for a successful SOA testing strategy:

1. Create an assembly-oriented plan: SOA and integration projects are fundamentally different from traditional application development projects. In these projects, much of the logic is in the connections between applications, not within the applications. Coordination and planning from an end-to-end perspective are key. There are several ways to make a dramatic difference in SOA projects. The first requirement is a project/program manager with an organizationwide view, not strictly an application orientation. Second, create an assembly-oriented plan that incorporates traditional code construction and validation, but is process-focused and has an incremental assembly orientation. The challenge is that most companies are still organized into application or business unit silos.

2. Focus on the business processes in requirements and testing: Focusing on the business process sounds simple. In reality, testing a business process means having many components available: applications, middleware, supporting technologies, and teams that support each one. Because processes run across applications and technologies, project managers report that coordinating testing is often one of the biggest problems and often a source of unpredictable delays.

3. Develop a testing team that understands and can validate integration: Another challenge to the broad business focus is ensuring that testers have the broad knowledge of business processes. This includes an understanding of the domino effects that are part of the intricacies of business transactions. The ability to work in cross-functional teams and work in a knowledge acquisition and knowledge transfer culture is an essential skill for SOA testers. Developing cross-functional teams of business users and testers and deploying testers that specialize in testing connectivity are two ways that successful SOA teams have created process-centric testing teams.

4. Test integration connectivity in all test phases: unit, component, integration, and end-to-end.

   Armed with an understanding of the business processes, testers have the ability to access the underlying technology to follow and validate the process. In the past, QA teams have required developers to write hundreds of stubs and harnesses, creating substantially more “test code” to be validated. In recent years, though, integration-oriented test tools have made accessing and testing SOA’s underlying connectivity much simpler. The important transition for testers is not to focus solely on the code, but instead find productive ways to understand and diagnose connectivity.

   Invariably, integration teams attempt to assemble all components of the system during the end-to-end testing phase where the results of integration problems are first discovered. To avoid this pitfall, it is necessary to test SOA projects at every phase using a consistent testing methodology that will work across all phases. SOA projects are assembly projects. The only way to effectively test SOA projects is to start from the ground up. First, in unit testing, test the inputs and outputs of individual modules. Second, put sections of logic together and test smaller sections of the integration flow. This new testing phase is called the “assembly” phase. This critical step is the equivalent of logically assembling a Tinker Toy model one piece at a time. Once this is accomplished, an end-to-end test can be performed on the fully assembled Tinker Toy model. Using this process, the end-to-end test is truly a final validation of the full process, and not the starting point for debugging integration logic.

5. Create an automated and repeatable testing process: As with any other testing process, repeatability is important, but even more so with SOA projects. The high number of permutations and combinations of paths through the system prove a daunting challenge for SOA projects. Building a regression library that can be run when even minor changes are made is the only way to efficiently reduce integration-level errors in maintenance mode. Although testing early when errors are easy to find has always been a testing tenet, the domino effect of a small error in an SOA environment makes comprehensive regression testing essential in an SOA project.

6. Plan for typical SOA testing hurdles (e.g., unavailable systems): One recurring problem with testing integration is that not all the components needed to test are available. Whether the missing application is an internal module, a vendor application, or a feed from a mainframe system, waiting creates substantial timing and coordination delays in integration projects. The ability to simulate unavailable systems is a must to keep SOA testing on track.

   Whether your SOA initiative is a new development effort or has been in place for some time, an SOA-oriented testing strategy can dramatically improve the delivery and cost of SOA systems. To effectively validate SOA systems, teams need to think along SOA lines and become assembly and end-to-end focused. Instead of thinking like sprinters, it is necessary to think like a relay team and focus on the handoffs.