[Previous] [Contents] [Next]
Library Staff Organization
From the beginning the emphasis was placed on involving as many staff as possible and including staff from both public and technical services. A Public Services Task Force, which included staff from all library departments, was formed. The Task Force appointed subgroups to concentrate on the different aspects of the conversion, like filling out the worksheets for the different modules and handling the data conversion. One group's job was to coordinate, train, and monitor a large group of staff on evaluating TestPAC. These testers came from different areas of the library and they were trained specifically on TestPAC evaluation.
Rationale for Testing
Each library has very different requirements when it comes to testing the new database. This is dependent on their old system and their needs with the new software. When first beginning the whole process, staff should first consider their specifications and spend a lot time on the Database Profiling worksheets. Whomever is working on the specifications should: 1) Know the history of your current system and any earlier migrations, 2) Know what both your new and old vendors will and will not do for you, 3) Be familiar with the INNOPAC and willing to ask Innovative questions, and 4) Know enough to follow up on these questions. The second thing to consider carefully is the instructions you give your database vendor on how you want your old data to be converted. Testing verifies that all of the above has been done correctly and to your satisfaction.
Types of Control Records
It is important to have a set of records that you can use for testing purposes. These are records that you have selected before the conversion begins so that you can see what they look like once the conversion is completed. It is important to select different formats and types of records so you can make sure that all of the data is transferring correctly. Choose records that are for serials, computer files, maps. Choose long records, short ones, records in foreign languages and with diacritics. Choose records with correct values, but also include some records to which you have knowingly added some incorrect values to see how the system deals with this. You also want to include dummy records which you create beforehand in the old system and which test to see if all the fields and subfields index correctly. An example of a dummy record can be found in the conference binder.
Development of Training and Testing Materials and Procedures
Each person recruited to be a tester received a packet, which included Database Profiling and OPAC worksheets. Many worksheets were combined and condensed to make more sense to the testers. They also had guidelines for testing, a schedule, and the III TestPAC Worksheet. An example of this worksheet can be found in your conference binder. Catalogers trained the testers on the different MARC fields and on the specifications laid out in the worksheets. Testers were carefully trained on the process of evaluation as well.
Testing the TestPAC
One room was set aside as a control center with PCs set up. Telnet access to TestPAC was also made available on staff PCs. The testers were all given 17 control records to look at. There was a print-out of each control record from the old system, and testers were to print-out the same record in the new system. The TestPAC Worksheet was the backbone of the testing procedures. On this worksheet testers indicated if something was working the way it was supposed to or if it did not seem right. Including the date on these worksheets was very important so the testers could go back through the worksheets and see if Innovative fixed what needed to be fixed.
Design of the OPAC Screens
The arrangement and design of the OPAC screen improved throughout TestPAC with all the input from the testers as they used the system. Changes were made in the records and in the indexing as the testers explored how the staff and student users of the system might best understand the searches and search results.
Specific Indexing Decisions: Author Fields/Author Title Index/Notes fields etc.
These included putting the 505 field in the keyword index but also putting subfield t of the 505 field in the title index. Also both the 780 and 785 field (proceeding and succeeding journal titles) were not included in any index so that patrons would not be misled by finding journals the library does not necessarily own.
Efficient and frequent communication was key in this whole process. The testers needed to be in communication with each other constantly as they went through this. During the day e-mail was used to let each other know if something wasn't working at a particular time or if someone ran into a problem. A blackboard in the Control Room kept track of all problems that testers ran into that day. Sometimes a "huddle" would be called when as many testers as possible would gather in the Control Room to discuss problems and what to do about them. One person communicated with Innovative and then passed all communications along to the testers.
What Did We Learn At Colorado State University?
1) Change is always disruptive to staff and others.
2) Incorporating all areas of the library was useful in getting people enthusiastic and excited about the change. They felt a part of what was happening and, therefore, were more positive.
3) The initial Task Force is still in place and now is a permanent group that deals with system issues.
[Previous] [Contents] [Next]