Changes to Testing Methods for SOA

The adoption of SOA for agility, reducing lifetime cost of an application or accelerating time to market for new business features, does require a change in your current testing strategy. These changes will reduce the amount of time it takes to test, enabling you to move faster through test cycles, and will require new activities (e.g., automated continuous regression testing). Complete testing of all possible paths of a program, an application, or system has become impractical if not cost-prohibitive for organizations (and has been for some time). There are just too many paths through a program to test; Yet, defects exist, and organizations must do intelligent testing and full life cycle testing such that defects are identified. For many test teams or test groups, deploying business applications into production with defects is way of life, where defects are now categorized and workaround techniques are communicated in lieu of fixing the defects. It does not have to be this way.

SOA provides an opportunity to improve testing when using services. The use of services promotes black-box testing, where functional tests can focus on valid inputs and outputs. The service contract defines valid inputs and expected outputs of a service, which promotes the use of black-box testing and tools to test the service. Blackbox testing eliminates the need to perform complete testing of all possible paths of a program, application, or system. In most environments, testing of a changed or newly deployed application requires retesting of components in the new system and their connections to downstream systems. This testing cycle is fraught with errors. Often, it must be performed in a linear fashion, and calendar time is slowly eaten away, causing a decision to either delay deployment, turn off features, or simply to live with defects in a production system (where operator workarounds replace functioning software). SOA fixes this issue because a deployed and working service does not need to be retested or included in future test cycles when reusing the service and deploying a new applications that uses the production-deployed service.

Figure shows the difference of scope with business applications before and after adopting SOA. In Figure, the scope of what needs to be tested is larger before SOA. The scope of the test cycle is less with the use of services when a service life cycle is introduced, where each service goes through a testing cycle in the same manner as we treat applications. Just like applications, services do not have to be retested after they are deployed into production. Services can be certified as satisfying their contract specifications. This certification provides consumer’s confidence that the service works as designed and results in less overall testing when applications are structured using services.

      With SOA adoption, where services are the structuring element of the application, black-box testing becomes the norm. This avoids the retesting of services already deployed in production to determine whether the new system, application, or service has a bug, because services working in production continue to accept the proper inputs and deliver the correct outputs according to the service contract. SOA testing is facilitated when automated continuous regression testing is used. Regression testing facilitates the rapid testing of services as black boxes to ensure the service contracts and services work as planned. Test drivers also prove useful for enabling the consumer to test the provider service in a controlled environment and without always having the platform of the service provider available. Service virtualization testing products enable test teams to mimic the functionality of a service based on its contract design before the implementation is developed, which further improves the quality of the service.