The STCL test tools architecture

Abstract

The Software Test Community Leaders (STCL) group is an IBM-wide initiative focused on improving software test and quality practices within the corporation. In 1999, we began working to develop an architecture to integrate both new and existing test tools into solutions for use in the testing organizations across IBM. This paper discusses the requirements for the architecture, as well as the issues associated with developing a solution architecture for a large base of tools that span a variety of platforms and domains. The architecture is being designed and developed to address three concerns for integrating testing tools: integration of the data across tools and repositories, integration of the control across tools, and integration to provide a single graphical user interface into the tool set. Because of the heterogeneous nature of the platforms and domains the architecture must support, extensibility is essential. We address each of these three integration concerns using an opensource framework that operates on a set of standardized but extensible entities.

Validation of Software Architecture for Object-Oriented Testing using with the Facilitate Quality Attributes

“…Increasing the completeness of a requirements specification can decrease its consistency and hence affect the correctness of the final product. Conversely, improving the consistency of the requirements can reduce the completeness, thereby again diminishing correctness [20].Davis states that completeness is the most difficult of the specification attributes to define and incompleteness of specification is the most difficult violation to detect [31].According to Boehm [22], to be considered complete, the requirements document must exhibit three fundamental characteristics: (1) No information is left unstated or "to be determined", (2) The information does not contain any undefined objects or entities, (3) No information is missing from this document. The first two properties imply a closure of the existing information and are typically referred to as internal completeness.…”

“…Huang and et al, describe the basic rules for program testing, which provide basic principle for testing [3,10,14,15,16,17]. Poston [26], Williams [27], and Hareton [19] shows, Integration all the data across tools and repositories, Integration of control across the tools and Integration to provide a single graphical interface into the test tool set. Limitation: emphasize only integration tool (usability & portability).…”