DCB testing process

Introduction

We’ve designed the testing process to be just-in-time and outcomes based. Just-in-time means that we will only assign testing in the week where the product is ready to deliver and available for testing. This allows us to be narrowly focused on the test cases that are ready for testing. Outcomes based means that detailed steps from the beginning of a workflow to the end should either be well-known to the tester (as in the case of processing a paged request in Sierra) or relatively easy to discern by the tester (as in the case of producing search results in LOCATE DCB). Practically speaking, it means that we will not provide a detailed set of steps to conduct the test and, instead, rely upon your systems knowledge and domain expertise to exercise the steps needed to produce the outcomes or, test results.

Testing and Reporting

Use the OLF Jira instance to manage testing and reporting of possible defects. There are two types of issues – Test Case issues and Testing Feedback issues – which are intended for documenting use cases and expected outcomes, and for reporting issues and maintaining or watching the state of an issue. Any issues identified as defects will result in a corresponding ticket opened in Jira or Rally and will be trackable.

A new set of test cases will be documented at the beginning of each week within a Jira “test case” issue type with testing feedback sub-tasks assigned to each tester.

Jira workflow

1. At the beginning of the week, the Product Owner will add a new Testing Feedback sub-task (manually or through import). Testing feedback sub-tasks are then assigned to the individual testers.

2. After testers review the test cases and have resolved any questions, transition the Testing Feedback issue to Mark Ready for Review from the status menu and it will move the issue into the working Backlog.

3. When testing begins, the tester will select Start Testing on the respective Testing Feedback issue, which sets status as In Progress. When appropriate, please feel free to create and attached screen recordings or screen captures and attach to the Testing Feedback issue.

4. If a test case is being skipped, select Close the issue from the status drop with a resolution of “Won't Do”.

5. If the behavior is satisfactory, transition the status to Closed, with a resolution of Complete.

6. If there is unexpected behavior, select Kick Back for PM Review.

7. When it's in PM Review the PO can triage and either move to Closed in the case where the report is considered expected behavior or, Park for Development which transitions to a status On Hold pending completion of a related Bug or Story issue (artifact to describe the undesired behavior). This is a separate issue created in Jira (K-Int Team) or Rally (Dreamliner Team) or wherever as appropriate for the team doing the work. 

8. The PO will add a link in the External Issue field if the issue resides outside of Jira. Or (if in DCB Jira) link the new Bug/Story issue to the Test Case or Testing Feedback issue with the `User Feedback` link (ie, [Bug/Story] "reported by User Feedback Issue" [Testing Issue])

9. When the prior step is complete, the PO and the testers re-test against the original testing feedback issue and transition to Return for Review which returns it to the Backlog.

10. The PO should/may need to move it to a new tighter scoped Test Case issue if it's a new test cycle.

Flowchart of Jira workflow

Tip: the Jira workflow can be found in within the state transition menu.

Cadence

• When a new testing cycle begins, EBSCO/K-Int will add test cases and testing feedback to Jira and assign to the corresponding testers.

• For deployment to the beta environment, Mon-Tue will be used to build, test and release the software into the beta environment.

• Wed-Fri are considered testing days.

• The system will be available each weekday between 6am and 9pm eastern.

Resources

Testing clustering with the Scaffold app

DCB Hub Discovery Scaffold App

Locate DCB beta environment