Controllability of a program (or component) is an important property which indicates how easy to control a program (or component) on its inputs/outputs, operations, and behaviors [2]. Component developers look at the "controllability" of a software component in three aspects: a) behavior control, b) feature customization, and c) installation and deployment. The first has something to do with the controllability of its behaviors and output data responding to its operations and input data. The next refers to the built-in capability of supporting customization and configuration of its internal functional features. The last refers to the control capability on component installation and deployment.

Test engineers and component customers concerned about other factors of component controllability, which may directly affect the component testability. The trace controllability in software components is a typical example. Testers and customers expect components to provide a set of control functions in software components so that they can use them to monitor and check diverse component behaviors according to their needs. We believe component trace controllability is very useful in component debugging, component integration, and system testing. In addition, component testers and customers expect software component vendors to generate components with test controllability to support acceptance testing and unit testing in a standalone mode. Component test controllability refers to a component's capability of retrieving and exercising component tests. Unfortunately, most current component vendors do not provide components with this capability due to the lack of research results on how to design and develop testable components.

Component understandability depends on how much component information is provided and how well it is presented. Presentation of component documentation is the first factor. For a component, there are two sets of documents. The first set is written for users. It includes component user manual, user reference manual, and component application interface specifications. The other set is written for component engineers, including component analysis and design specifications, component testing and maintenance documents. The second factor to component understandability is the presentation of component program resources, including component source code and its supporting elements, such as its installation code, and test drivers. The final factor is the presentation of component quality information, including component acceptance test plan and test suites, component test metrics and quality report. Most current third-party components did provide users with component user manual and application interface specifications. However, only some of them provide user reference manual, and most of them do not provide any quality information. Although it seems reasonable for component vendors to hide detailed test information and problem information, customers will expect them to provide quality information, acceptance test plan, and even test suites for components in the near future.

Considering the evolution of software components, we must pay attention to the reuse of component tests. The primary key to the reuse of component tests is to develop some systematic methods and tools to set up reusable component test suites to manage and store various component test resources, including test cases, test data, and test scripts. In the current engineering practice, software development teams use an ad-hoc approach to creating component test suites through a test management tool. Since existing tools usually depend on different test information formats, repository technologies, database schema, and test access interfaces, it is difficult for engineers to deal with diverse software components (for example, third-party components) with a consistent test suite technology. This problem affects the reuse of component tests in the component acceptance testing and component integration.

To solve this problem, there are two alternatives. The first is to create a new test suite technology for components with plug-in-and-test techniques. With this technology, engineers are able to construct a test suite for any component, and perform component tests using a plug-in-and-test technique. Clearly, it is necessary for us to standardize software component test suites, including test information formats, test database schema, test access interfaces, and to define and develop new plug-in-test techniques to support component unit testing at the unit level.

The other alternative approach is to create component tests inside components, known as build-in tests. Unlike the first approach, where component tests created and maintained in a test suite outside of a component, this approach creates component tests inside components. Clearly, it simplifies component testing and reduces the component test cost at the customer side if a friendly test-operation interface is available. To execute the built-in component tests, we need extra function facilities to perform test execution, test reporting, and test result checking. Therefore, there is a need to standardize test access interfaces supporting the interactions among components, test suites, and built-in tests.

An ideal testable software component is not only deployable and executable, but also testable with the support of standardized components test facilities. Unlike normal components, testable components have the following features.

There are three questions regarding to design of testable components. The first question is how to design and define the common architecture and test interfaces for testable components. The next question is how to generate testable components in a systematic way. The final question is how to control and minimize program overheads and resources for supporting tests of testable components.

Now, in the real world practice, engineers use ad-hoc approaches to developing module-specific or product-specific test drivers and stubs based on the given requirements and design specifications. The major drawback of this approach is that the generated test drivers and stubs are only useful to a specific project (or product). It is clear that the traditional approach causes a higher cost on the construction of component test drivers and stubs. In the component engineering paradigm, components might have the customization function to allow engineers to customize them according to the given requirements. This suggests that the traditional way to construct component test drivers and stubs is very expensive and inefficient to cope with diverse software components and their customizable functions. We need new systematic methods to construct test drivers and stubs for diverse components and various customizations. The essential issue is how to generate reusable, configurable (or customizable), manageable test drivers and stubs for a component.

Component test drivers must be script-based programs that only exercise its black-box functions. There are two groups. The first group includes function-specific test drivers, and each of them exercises a specific incoming function (or operation) of a component. The second group contains scenario-specific test drivers, and each of them exercises a specific sequence of black-box operations (or functions) of a component.

Component test stubs are needed in the construction of component frameworks. Each test stub simulates a black-box function and/or behavior of a component. There are two general approaches to generating test stubs. The first approach is model-based, in which component stubs are developed to simulate a component, in a black box view, using a formal model, such as a finite state machine, a decision table, or a message request-and-response table. Its major advantage is model reuse and systematic stub generation. To cope with component customization, we need a tool to help us change and customize an existing model, and generate a new model. The second approach is operational script-based, in which test stubs are constructed to simulate a specific functional behavior of a component in a black-box view. The major advantage of this approach is the flexibility and reusability of test stubs during the evolution process of components. However, the challenge is how to generate these function-specific test stubs in a systematic manner.

In general, a program test execution environment consists of several supporting functions: test retrieval, test execution, test result checking, and test report. Clearly, a component test environment must include the similar supporting functions. The primary challenge is how to come out a new component test-bed technology that is applicable to diverse components developed in different languages and technologies.