Beta Testing an Integrated Library Automation System

Article excerpt

The opportunity to become the beta test site for KeyNOTIS[TM], the turnkey library automation system offered by NOTIS Systems, Inc., was presented to Pfau Library, California State University, San Bernardino, in 1989. There are advantages and disadvantages, as well as risks, for both the vendor and the test site in such an arrangement. The beta test was successful and the product accepted by the library after overcoming many obstacles along the way.

The automation of a library is a very complex task best achieved through careful planning and decision making, involving extensive discussions with vendors, securing generous funding, performing complex file and site preparation, and coordinating by an experienced library automation specialist. In the real world, however, we do not always have the time, money or staff to do a thorough job of preparation and planning. For Pfau Library, the opportunity to be a beta test site both enabled us and forced us to automate without all of the above recommendations being fully met.


Beta testing is the trial use of developmental software or hardware, in the environment for which it was designed, before it is released commercially. Usually beta testing is performed on fully developed, market-ready products after most of the debugging has been done during alpha testing by the development company. (1,2) This article, based on the experience of Pfau Library at California State University, San Bernardino (CSUSB) in beta testing the KeyNOTIS integrated library software, will examine some of the advantages and pitfalls of beta testing and suggest some things to consider before entering into a beta test agreement. It will also make suggestions relevant to the undertaking of any major automation project, whether or not as a test site.

A potential test site must determine that it needs an automated system that can perform certain well-defined functions, and that the product being considered is intended to perform these functions. The site must be seriously interested in the product being considered. The vendor needs to determine that the potential test site has the staffing, facilities, and funding necessary to carry out the beta test and to become a satisfied customer. The vendor should also determine that the product will meet the needs of the potential test site.

There are advantages for both the vendor and the test site in participating in a beta test project. The vendor has an opportunity to find and correct software errors and to get customer feedback on what works well and what needs improvement. Planning for enhancements for the next release of the software is likely to begin during the beta testing phase. The vendor gets feedback on the documentation and training that accompanies the software being tested. Depending on the beta test agreement, the vendor may also receive some prerelease advertising and a demonstration site along with the beta test.

Advantages for the test site include access to new software or technology and the opportunity to be in the forefront of a rapidly changing field. Access to the new software and the beta test experience itself can hold significant learning experiences for staff members at the test site. Additional advantages may include free or discounted hardware or software, and extra support from the vendor during implementation and testing. Although the software will be in its final stage of development, the test site may have some influence on its future development.

There are also disadvantages for the test site that must be taken into consideration. The beta testing process itself takes more time and effort than would be needed during the installation of an established product. There will be some time spent identifying and resolving software errors. Much of this will be done by test site staff working with the vendor over the phone. The beta test site may be under pressure from the vendor to meet short deadlines that would not have been imposed in a nontest situation. …