The STCL test tools architecture - Software Test Community Leaders

IBM Systems Journal,  March, 2002  by C. Williams,  H. Sluiman,  D. Pitcher,  M. Slavescu,  J. Spratley,  M. Brodhun,  J. Mclean,  C. Rankin,  K. Rosengren

• E-mail
• Print
• Link

In 1998, IBM formed the Software Test Community Leaders (STCL) group to address issues associated with software testing and quality. The group consists of key technical professionals and managers from testing groups across the various divisions of IBM. They collectively represent the depth and breadth of software testing expertise available within the corporation. One of the first tasks the technical team undertook was to identify and categorize leading tools and practices in use across the divisions, with the idea that this would enable key tools and practices to be shared. As a result of this exercise, the team produced a list of best practices with supporting tools and discovered two problems that would inhibit tool and practice sharing.

1. Different labs within IBM had different tools supporting the same practice. A variety of manual, STCL supported, and third-party or homegrown tools are used across labs within IBM.

2. Testing groups were mixing manual processes with both STCL recommended and homegrown and third-party developed tools. Because these tools were not designed to work together, human intervention or custom integration was required (Figure 1).

[FIGURE 1 OMITTED]

The multitude of tools with similar functionality within IBM is due to the variety of platforms and products the corporation develops and supports. Also, different labs across IBM have variations in their testing processes. A process is composed of one or more testing practices. While the practices might be basically the same, the processes that the practices support can be markedly different from lab to lab. This leads to the development of tools customized for site-specific processes, even though they are based on practices that are common throughout the corporation.

In mid-1999, the STCL technical leaders decided to take an architectural approach to addressing these two problems. The STCL Architecture Committee was formed from a subset of the technical leaders who represented the various labs and were interested in developing an architecture. The committee started its work by exploring high-level solutions that described how tools might interoperate when supported by an architecture. Figure 2 shows one example of such a solution. The group developed other views as well, with the ultimate goal being an architecture that would provide support for customizable solutions.

[FIGURE 2 OMITTED]

In the remainder of the paper, we cover the following topics. First, we discuss the requirements that the architecture must satisfy. Then we present the architecture, focusing on three concerns: data, control, and GUI (graphical user interface) integration. Next we discuss how new tools can use the architecture, how legacy tools can be integrated, and how the architecture meets the requirements. Finally, we present conclusions and future work.

The requirements

At the highest level, there are three requirements that the architecture must meet:

1. It must provide a mechanism for integrating the variety of tools recommended by the STCL.

2. It must support site-specific tools and testing processes.

3. It must support legacy tools, while also providing a road map for new tool development within IBM.

The problem of integrating heterogeneous, independently developed tools has received attention from other parties, both inside and outside IBM. (1,2) The integration is usually accomplished using a three-phase approach, which includes data integration, control integration, and interface integration. This is the approach that the STCL architecture committee selected, and it led to a more detailed set of integration requirements:

1a. Data integration must make test-related data available in an open manner regardless of the tool or repository in which the data are stored.

1b. Data integration must provide a way to maintain associations among related data, even if the data reside in different repositories.

1c. Control integration should support invocation of externally available functionality on tools that comply with the architecture. This will be important for building highly automated testing environments.

1d. GUI integration will result in a single user interface for accessing all of the architecturally compliant tools.

1e. GUI integration should not preclude using the tools as they are currently used today. This is important because different groups will migrate to the new architecture as business conditions permit.

In order to meet requirement 2 (support for site-specific tools and processes), we developed the following set of more detailed requirements:

2a. A "plug-and-play" mechanism for incorporating site-specific tools must be part of the architecture. This mechanism should be easy for tool owners to adopt.

2b. Control integration should allow workflow customization to support variations in the testing process.

By "plug-and-play," we mean that a tool that has complied with the architecture should be able to be incorporated by a testing group into an architecture-based solution with minimal effort. Furthermore, this solution should support customization of processes using a workflow definition language.