Testing Sierra circulation

Introduction

The intention of this round of testing is to cover the major use cases for resource sharing via DCB. What is reflected “in scope” is approximately 80% of the use cases required to have a complete solution supporting resource sharing. Over the coming months, the remainder of the use cases will be developed, tested and then supported on-going for Sierra, FOLIO, FOLIO ECS and Polaris.

In scope

• Sierra libraries

• Item requesting

  • Patron affiliation

  • Patron authentication

  • Pickup location selection

• Full happy path circulation lifecycle

  1. Lending – produce paging slip → checkin (to trigger hold) → put in-transit to pickup location + produce in-transit slip

  2. Borrowing – hold → checkin (received) + produce hold slip + put on-holdshelf + produce pickup notification → checkout to patron + date due slip → checkin from patron + put in-transit + produce in-transit slip

  3. Lending – checkin + remove transaction

  4. Borrowing – remove transaction (transaction complete)

• Patron cancellation of a request

  1. Borrowing – Patron account in OPAC or Discovery → cancel request → remove hold

  2. Lending – remove hold (transaction complete)

Not in scope

• Polaris, FOLIO, FOLIO ECS platforms

• Volume-level requesting

• Patron eligibility/blocks

• Pickup anywhere

• Geographic proximity item selection

• Item owning site cancellation

• Transfer to another item

• Renewals

• Holds

Configuration

As much as possible, circulation configuration is modeled after the existing INN-Reach configuration. DCB virtual patron types and item types.

• Sierra

  • Circulation rule determiner and corresponding loan rules

  • Patron notifications

  • Staff slips

    • How to differentiate between local requests and DCB requests on a paging slip? The name field (Labelled name on the pull slips, but actually uniqueid) is a clue and will be PatronIdAtHomeSystem@HomeSystemCode e.g. 1234@3myagency (Where my agency is the home of the remote patron who is placing this request)

• Relevant configuration files

  • Item type mapping

  • Patron type mapping

  • Pickup location mapping

  • Agency mapping (missing SEMO and SGPL)

Testers

Each working group member will be paired with another working group member from another institution.

Test records

Each library will need a patron, a bib and an item to conduct testing. You can use preexisting or newly created records but the key is to make sure that your library solely owns the title. This will prevent the system from directing requests to another library. Some guidelines for each record type:

• Ensure that your patron record is eligible to request and mapped to an eligible INN-Reach central patron type.

• Confirm that the bib record is in LOCATE DCB. If you create a new bib, do not suppress it as we have not yet fixed the DCB suppression logic.

• For the item record, please ensure that it is locally requestable and mapped to a requestable INN-Reach central item type.

We strongly suggest that the records are fully defined as if they are a legitimate part of your catalog or your patron database. This will best exercise the software and allow for the surfacing of issues within Sierra client displays (e.g. check-in and checkout, holdshelf), within notices and slips, and within public patron account features.

Test records spreadsheet (to transfer to Jag’s Test Record Template)

Test record template (use this instead of the spreadsheet)

Test guidance

There are 2 test cases – 1 for the lending side and 1 for borrowing side. Every member is assigned testing feedback issues for test cases as a borrower and as a lender.

• Each group will decide who first plays lender while the other plays borrower.

• Then, you’ll switch roles.

• As you are working through each test case, please make notes along the way within testing feedback comments.

• Also, please take screenshots of the test records and add them to a comment on the assigned Jira testing feedback issue.

Our expectation is that you will collaborate together on a complete workflow, ideally using video conferencing capabilities to share screen when playing your part while your partner observes the outcome of each step and records observations, especially unexpected behavior, in the Jira issue.

• If you can capture via conference recording, even better.

Understandably, some processes may be difficult to capture or run in real-time, for example, producing paging slips.

• If you already have a method for producing paging slips containing a test entry (for instance, while training a new staff member), please use it.

• If not, please reach out to your fellow WG members or Tim Auger for ideas.

To capture as much information as possible, each member should examine and record the state of the real and virtual records in each system throughout the entire transaction.

• For example, after successfully placing a request, check the records in each system.

• For example, does the patron record have a corresponding virtual item?

  • What does it look like?

  • What is the state of the virtual record?

  • Can you find it in inventory?

  • On the lending side, does the hold appear on the item?

  • When producing a paging slip, does it have the requisite information to find it on shelf?

  • Upon checkin, does the hold get triggered and are you prompted to produce an in-transit slip?

• And so on…

If something looks out of the ordinary, please record it and, so long as it does not prevent moving through the normal course of operation, please keep going. Take your time working through the scenarios and, ideally, capture your testing via a video conference recording tool.

If you want to run through the tests multiple times, feel free! You can use the same records or different records so long as they meet the criteria outlined in the above “Test records” section.

Note: despite using INN-Reach-like configuration, the DCB workflow is designed to be completely integrated within local circulation operations.

Advice: I encourage you to think of the DCB transactions as if they are requests from a different branch. This is the workflow we are hoping to mimic. That said, we may need to make adjustments to configuration and code along the way so please be patient with the process. In the end, we seek to achieve an optimized process without skimping on the requirements to successfully operate within standard circulation workflows.