Browse Prior Art Database

System and Method for Providing Metrics on the Complexity of an Integration Verification Project

IP.com Disclosure Number: IPCOM000019777D
Original Publication Date: 2003-Sep-29
Included in the Prior Art Database: 2003-Sep-29
Document File: 5 page(s) / 127K

Publishing Venue

IBM

Abstract

System and Method for Providing Metrics on the Complexity of an Integration Verification Project

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 5

  System and Method for Providing Metrics on the Complexity of an Integration Verification Project

  Integration verification is in many ways today practiced as an art rather than a science. Manual testing is common, and leads to a false confidence in the stability of our products. As a result, methods to improve our ability to quantify how difficult an integration problem is, and to communicate precisely where effort was spent in such testing, is sorely needed.

Our solution to this problem centers around adding rigor and formalism to methods that are common in integration verification, such that quality assurance teams can consistently model and describe their verification efforts, and more clearly identify areas to focus on and areas of risk to accept. While these methods have been applied in other phases of testing (e.g. unit test, functional test, and even system test), in the area of integration testing specifically, such methods and tools are completely lacking.

2. Summary of Invention: Briefly describe the core idea of your invention (saving the details for questions #3 below). Describe the advantage(s) of using your invention instead of the known solutions described above.

The best way to summarize the solution we are proposing is through the use of an example. One of the products we are responsible for integration testing on is TEC (The Tivoli Enterprise Console). There are a wide range of products -- some Tivoli products, some from other vendors -- we must successfully integrate with. In addition, there are databases that we must be able to interact with, network oddities, etc. So for example:

1

Page 2 of 5

This figure represents a good proportion of these products, databases and other conditions that are needed for effective integration testing. Further, for each of these products, there are a wide range of different versions, potentially. Considering just ITM as an example:

2

[This page contains 1 picture or other non-text object]

Page 3 of 5

There are often multiple versions of individual products that must be able to integrate, and still further,

3

[This page contains 1 picture or other non-text object]

Page 4 of 5

Often multiple patches for key products -- sometimes several dozen.

As can be se...