May 1999

TAPI Testing Today

BY MARK S. FISHER

TAPI-compliant devices and applications entered the market at the SOHO and small business level, migrating toward the general business environment. During this migration, the number of vendors has grown tremendously. As new products enter the marketplace, the need to test for conformance to standards, the ability to work with other devices or applications, and the ability to handle required volumes become crucial. Robust, easy-to-use development and testing tools are needed to insure proper system performance across multiple vendors' products. In this context, applications and hardware testing are major stabilizing elements.

WHAT NEEDS TO BE TESTED?
In the CTI development environment, the two major components are the application and the Telephony Service Provider (TSP). Multiple instances of these components coexist on a Windows 95/98 or NT platform and exchange data routed by the TAPI middle layer. The data exchanged consists of API calls, messages, and data structures. An analysis of this environment isolated the problems that can occur during the development of a computer telephony system using TAPI:

• The application developer must make decisions based on a significant amount of data received from the TSP or TAPI middle layer.
• There are different interpretations of the TAPI specification by vendors, so implementations may differ.
• Application and TSP developers are not able to communicate to clarify the interoperability problems.

In order to isolate development problems and shorten the development cycle, different test methodologies can be used.

TSP TESTING
If the device under test (DUT) is a TSP, adequate scenarios to implement the test methodology must be created to allow testing. The typical tool for creating these scenarios is a TAPI-like application that is easy to modify and configure. This application should provide a detailed level of analysis of the data exchanged with the TAPI middle layer. Following are some typical types of testing to be performed during the product development cycle and the appropriate test scenarios to be used:

• Functional Testing: Does the TSP perform basic TAPI functions? Test scenarios address the basic TAPI function calls and the call progress.
• Conformance Testing: How are data structure elements filled by the TSP? Do API return codes and messages sent to the application (routed by the TAPI middle layer) conform to the TAPI specification? Test scenarios check conformance of the data structure elements and check the order and timing of the messages.
• Regression Testing: Is the current release backward compatible with previous releases of the TSP? Test scenarios focus on new features implemented in the DUT while repeating the scenarios from previous releases, in order to maintain a high level of confidence in backward compatibility.
• Interoperability Testing: Do various applications work with the TSP under test? Test scenario: To check the interoperability of TSP X with an application written for TSP Y, select a test scenario that emulates the application and executes successfully on TSP Y and run it on TSP X. If the scenario executes successfully on X, the specific functions tested on X are interoperable with this application.
• Volume/Capacity Testing: What is the limit of the environment? What is the call volume that the device can handle? How does it simultaneously access critical resources? Does the system begin to behave erratically as its limits are met? Does it degrade gracefully as it exceeds its limits, or does it become unstable? Test scenarios simulate increased load on the system in call volume or resource allocation. Implement the real-life, worst case scenario.

During the product development cycle, the TSP developer is in a position to perform all the levels of testing mentioned above. The challenge is to succeed with minimal investment of time and money. To achieve these objectives and implement the desired test methodology, test tools require several critical elements:

• Creation of adequate test scenarios for the desired type of testing. Is the focus on API calls or on order of callback messages?
• Automation of test scenario execution. Can the system run a conference scenario between the same three stations all night?
• High level of analysis of the results. Does the test tool measure the consistency of the data structure? Does it measure the timing of the callback messages?
• Excellent level of reporting and result management for isolating errors. How many test cases failed in the last week? Why?

In order to test the volume/capacity of the system, very specialized tools must be used. Now, the scope of the scenario is no longer just an individual line, but all the lines available on the TSP. This is close to a real-life scenario. At this level of testing, the tool needs to have the following features, at a minimum:

• Execute test scenarios on different lines available at the same time.
• Perform analysis of the results at a single line, across multiple lines, and at a statistic level.
• Generate various volumes of calls across available lines easily in the test scenarios.

APPLICATION TESTING
If an application is the DUT, the testing should be focused on two major areas:

• Interoperability testing: The application must work with different TSPs and coexist with other applications in a Windows 95/98 or NT environment. Testing scenarios: test the application for interoperability in real-life scenarios with as many TSPs as possible. For call center or server applications, capacity testing is a requirement. It is necessary to know both the maximum number of calls that can be handled and how the system reacts up to and over this limit.
• Volume/Capacity testing: The application must handle a large volume of calls and not act as a restricting factor for overall system performance. Testing scenarios: capacity testing should report system behavior, as well as analysis across multiple lines.

With applications, the necessary tools for providing adequate testing must allow:

• Tracing of the data exchanged between the application and the TSP in order to isolate interoperability problems.
• Automation of GUI interaction for simulating real-world user interaction.

To summarize, in order to test a TSP or an application, a very clear test methodology must be created for the whole development cycle, and appropriate tools must be used in order to implement the methodology.

OTHER TESTING OPTIONS
In addition to testing the applications and TSP with specialized tools, there are some other opportunities that will shorten the deployment of the CTI product on the market. Bakeoffs and other testing forums provide another means for bringing different applications and TSPs to a common mode of operation, although alone they cannot provide a sufficiently vigorous or thorough testing environment. Certification and validation for TSP conformance to the TAPI standard can narrow the broad implementation recommendations in the TAPI specification. A certified TSP will be more likely to interoperate with various applications.

Mark S. Fisher is Product Marketing Manager Testing Tools, Facsimile, and Telephony for Genoa Technology, Inc. Genoa Technology is a world leader in the design, development, and marketing of comprehensive test solutions for computer telephony, imaging, facsimile, and connectivity technologies. for more information, please contact Genoa at 805-531-9030, or visit their Web site at www.gentech.com.

Interoperability news is always welcome in the CTI space, and standards-based systems represent the best hope for moving CTI services off of proprietary platforms - making these services more affordable, more accessible, and more competitive. Solid interoperability testing solutions must be available if new applications and devices are to succeed in the marketplace.

Microsoft Corporation's recent investment in Dialogic Corporation demonstrates Microsoft's interest in bringing telephony applications and developers to the Windows platform. To this end, both Microsoft and Dialogic are offering certification and validation programs for TAPI and CT Media to further the standardization process across multiple platforms and devices. Subjecting their applications to Genoa testing will allow developers to be "CT Media certified" and will allow TAPI service providers to take part in the "Designed for Windows" logo program. Genoa has informed CTI� they will be accepting applications for CT Media Interoperability Certification and the Designed for Windows logo program beginning in May of 1999.

For information on Microsoft's TAPI "Designed for Windows" logo program, visit Microsoft's Web site at www.microsoft.com/communications. Information about Dialogic's CT-Media Interoperability Certification Program can be found at www.dialogic.com/company/pressroom.