Whipping the QA Process Into SOA Shape

If you consider the traditional quality assurance process — in which QA is a set of tasks that occur in a serial fashion after development — it becomes clear that many of the desired SOA (service-oriented architecture) benefits such as agility, cost efficiency and higher quality are placed at risk. These risks are compounded by four very distinct QA challenges:

• Given the distributed and complex nature of SOA, it is virtually impossible to “stage” an SOA environment.
• Given the technical nature of the message layer, many QA staffers are not capable of constructing the necessary tests.
• Given the general definition of roles and responsibilities within QA and development, there is minimal collaboration on “quality assets.”
• Given the high level of integration, more business domain expertise is required to achieve robust tests.

The key to overcoming such challenges is achieving a “process cadence” that initiates the quality process as soon as services are defined. A collaborative and building-blocks approach to quality is particularly well-suited for handling the complexity that comes with SOAs. If businesses want to achieve agility through rapid incremental deliverables, then organizations cannot wait for a serialized quality process.

Shared Business Services vs. Application Centric

Ultimately, there are two approaches toward achieving an SOA: the top-down approach (shared business service) or the bottom-up approach (application-centric). Each of these approaches has distinct benefits and challenges.

Adopters of the shared business services approach have a distinct challenge when dealing with quality. Given the business process view taken with this approach, QA is faced with testing a process that crosses multiple application silos, multiple departments and perhaps external business units.

Adopters of the application-centric approach have a bit of a different challenge. From an application point of view, exposing an API (application programming interface) that leverages Web services, or other service-oriented protocols, is not a very difficult technical task. In most cases, given the application-centric approach, it does not make sense for QA to step in and exercise this modification. This is truly a developer task.

For either approach, in order to achieve agility, development must be responsible for testing the API, and QA must be able to leverage those tests in order to exercise a broader set of business scenarios. This is similar to the quality process that we can observe in the embedded systems world.

A Step-by-Step Approach

The following steps improve the process of quality and create process cadence:

ol.thisol { font-weight:bold }ol.thisol span {font-weight:normal }

1. Provide visibility. When exposing business information internally, or by sharing data with partners externally, the businesses goal is to demonstrate that each part of its system is reliable. Visibility will ultimately promote trust. Trust will ultimately promote reuse of these business assets.

   Internally, the organization has a distinct goal of promoting reuse of business assets. The challenge of reuse is truly a cultural shift in the way that developers and architects have traditionally delivered projects. Given this long-standing cultural barrier, the quality metrics need to tell a very distinct story for the internal constituents. The data should give the internal organization the confidence and trust that the business asset is robust enough for the application. The negative case is also true: The architect should also be able to determine that the service asset is not robust enough for the specific application.

   Externally, visible quality metrics truly provides a “credit report” for specific services. This credit report assists in eliminating the finger-pointing when it comes to on-boarding customers within an SOA — which is still an integration activity. Although SOA introduces more stable interoperable standards, integration with business partners still requires dedicated time and effort. Finger-pointing during this activity is still the norm. Having the asset credit report available to external partners assists to solve the finger-pointing.

   Promoting trust for an asset must begin early, as soon as the asset is created. Visibility into asset quality helps drive the development cycle and promotes trust for later reuse. In order to promote trust early, the business must define policies that govern the different aspects of the services life cycle, runtime and design time.

2. Supply an infrastructure for reuse. Reuse of service assets is an inherent aspect of SOA and one of its primary value propositions. Therefore, it is critical for the quality processes to evolve in order to fit the service reusability paradigm by adopting testing processes that reuse the underlying test assets.

   One key to establishing an efficient quality process is to have an infrastructure that allows for the reuse of test artifacts. You do not want people redoing, recreating and rerunning the same tests over and over again. You want to make sure that test assets are created, shared, leveraged and extended properly among team members in order to achieve maximum efficiency. In order to do this, you need an automated infrastructure that allows you to store these test assets — this can be something as simple as a source control system, or a more specialized test repository solution that is designed specifically to manage test cases and their execution details.

3. Promote bottom-up quality. Most businesses worry about the externally visible functionality of an application. However, because services can be reused, and reused in unpredictable fashions, ensuring quality at the message layer only is not sufficient. Besides, there are other considerations to quality: To what extent is the service maintainable and to what extent can it evolve with business needs?

   Therefore, you must also ensure that the underlying application is robust. To achieve quality at the application level, you must apply certain activities such as coding standards, static analysis and unit testing in an efficient manner. Once quality metrics and assumptions become clearly defined and visible in the underlying asset, they can be better trusted and reused.

4. Leverage the infrastructure for top-down quality. Top-down quality workflows are best embodied at the messaging layer of an SOA system. Top-down quality ensures that the service at runtime adheres to the quality requirements that are imposed on it. Top-down quality workflows are best embodied at the messaging layer of an SOA system.

   At the messaging layer, organizations must ensure that the service processes deliver the desired business requirements. This includes activities such as verifying WSDLs (Web services description languages), BPEL (business process execution language) files and design and development policies, as well as enforcing them consistently. Security should be addressed as part of the software development lifecycle rather than an after-the-fact activity.

5. Assist to manage complexity. In order to meet the demands of developing, testing and maintaining a complex SOA, you need to have an infrastructure that allows you to stub out and emulate individual components within the SOA. Because certain endpoints of the SOA may be out of your control, you must be able to emulate them. That is, you must be able to emulate endpoints such as service consumers, clients and service providers while also being able to create a test harness to emulate more complex processes such as asynchronous messaging and BPEL processes.

   Even more critical is the case of business-to-business partners where providers and consumers are not available. In this case, you need to provide a runnable test-driven development environment to permit both endpoints to work in parallel and to optimize the development process. The key here is to provide a development and test environment that is as closely similar to the production environment as possible.

6. Concentrate on quality process improvement. The optimal process is one that continues to improve. Because SOA introduces architectural and structural differences, it causes a separation between QA and development with architecture-heavy processes.

   The quality of the overall process is most vital at the architectural/business enablement level, and at the service/application/team level. Therefore, it is critical to have a unified dashboard that spans and ties these different levels, bottom-up and top-down, in order to measure and track the overall process quality.

Bridging the Gaps

These six steps will assist in bridging the gaps in the quality process. Promoting these tasks in an overall quality strategy will distinctly assist in evolving reusable business assets.

Furthermore, delivering the necessary process cadence will enable SOA quality as a continuous process, allowing the business to reap the full benefits of its SOA initiative.