Open World Testing
Introduction
During Open World testing, all MOBIUS member libraries will use OpenRS DCB in the pre-production (a.k.a. dress rehearsal) environment. Testing will serve as an opportunity to gain familiarity with the software and give everyone opportunity to confirm configuration. Since the pre-production environment is only connected to production environments, it is important to coordinate requesting and circulation testing with other members to ensure that daily operations are not adversely impacted.
As part of exercising the software, all member libraries will test a set of familiar use cases. Exercising these use cases are intended to give all of us the confidence that the software has been sufficiently vetted, across all platforms and that your library can move smoothly from using INN-Reach to OpenRS DCB. A set of member-created records will provide the vehicle to exercise the OpenRS DCB software. The content of these test records follows a strictly-defined syntax to support vetting the software against use cases.
During testing, if you encounter unexpected behaviors, please record your steps and report issues to MCO. Recording your steps can be performed in narrative, screen recording and/or video/audio recording form.
Use cases
This section contains three sets of use cases:
Union Catalog Build and Search
Please note that the Union Catalog Build and Search use cases will use existing records in your collection.
Capability | Use cases | Record sets | Notes |
Contribute and suppress bibliographic/instance records |
Pending
| Existing records from your collection | Reminder: the DCB harvests on a periodic basis. In production, it will occur between 4 and 24 hours. During the testing period, harvesting updates will occur every 2 minutes. |
Bib/Instance record clustering |
| ||
Union catalog searching |
| Existing records from your collection | Repeat the uses cases using a range of records from your collection. If you encounter unexpected behavior, please record your steps and send to MCO. |
Happy Paths for Requesting and Circulation
There are 4 scenarios for requesting with each exercising slightly different aspects of the requesting logic.
A solely owned title with 1 available item
A solely owned title with 1 available item and 3 unavailable items
A shared title with multiple available items
A shared multi-part title with multiple available items
While there is only a single happy path circulation use case, the requesting scenarios set the stage for variation in circulation rules and, hence, testing the configuration. With each requesting scenario, you and your partner will also run through the circulation use case. That is, you will exercise the happy paths for requesting and circulation a total of 4 times.
Please note that these use cases will use the member-created test records according to the section Test record template guide.
Use cases | Steps | Test records | Notes |
Patron – Requesting |
|
| After a successful request, a virtual patron and a hold on the requested item should appear in the supplier’s system. When finished with requesting scenario 1, move to the circulation use cases starting with “Lender – Supplying” and moving through the remainder of the circulation use cases. Then, move to requesting scenario 2 and when finished, move onto “Lender – Supplying” as you did with scenario 1 and so on. Rinse and repeat with scenarios 3 and 4. |
Lender – Supplying |
| Use the records corresponding from requesting scenario. | When the item is loaned to the borrower, the DCB will detect the loan and then perform a checkout to the virtual patron on the supplier system. Sierra will direct the user to put the item in-transit to the pickup location. Leap will direct the user to put the item in-transit to an ILL location. Within the Leap hold record, the note fields contains the borrower’s selected pickup location. |
Borrower – Loaning |
| Use the records corresponding from requesting scenario. |
|
Lender – Loaning |
| Use the records corresponding from requesting scenario. |
|
Borrower – Returning |
| Use the records corresponding from requesting scenario. |
|
Lender – Returning |
| Use the records corresponding from requesting scenario. |
|
Alternate Paths for Requesting and Circulation
Please note that these use cases will use the member-created test records according to the section Test record template guide.
Use cases | Steps | Test records | Notes |
Authentication |
|
| |
Eligibility |
| There are three ineligible scenarios listed here. Using the same patron record, exercise each independently from one another by modifying the patron record. Understandably, the automated blocks (excessive fines/fees/checkouts, etc.) may be more challenging to setup. Feel free to create separate records for each scenario. | |
Requesting |
| This case should result in a failure to present a hold button to the end user, hence not allowing a request. Current Locate DCB behavior is to show no holdings and not display a “Place a Hold” button. | |
| If there are more than three libraries with an available copy, this case should result in a test of the location proximity algorithm and settings. |
Additional use cases
Once the above use cases are complete, it’s time to cycle through related cases that will exercise the remainder of the MOBIUS Patron Type and Item Type mappings. Most MOBIUS libraries have each of the following types but, if not, just use the patron and item types that map to each of the MOBIUS types.
MOBIUS Patron Types
MOBIUS 10 BOOK-AV
MOBIUS 20 BOOK-AV
MOBIUS 30 BOOK-AV
MOBIUS 10 BOOK
MOBIUS 20 BOOK
MOBIUS 30 BOOK
MOBIUS Item Types
CIRCAV
Test record template guide
Every member library must create a set of test records to support Requesting and Circulation use case testing. Some records represent titles that are singularly owned and other represent titles that are shared with other members. The characteristics of these records are designed to be clearly distinguishable from other records in your systems. Following are sets of templates representing patrons, monographic and multi-part works and their items. In addition to Open World testing, these records are expected be used in ongoing beta testing, training and troubleshooting with MCO, EBSCO and K-Int support services after go-live so please maintain these records.
<library short name> is name of the library that you belong. For example, Springfield-Green County Library short name is “Springfield-Greene”. You can find the list of full, short names and abbreviations for all MOBUS members.
<library type> is the general type of library that you belong. Academic, Public, Special are valid types.
Patrons
Set | Template | Example |
---|---|---|
| Name: Tulsa Eligible | |
| Name: SEMO Ineligible |
Bibs/instances and items
Testing Partners
<>
Operated as a Community Resource by the Open Library Foundation