end to end testing kick why end to end (e2e) testing? e2e testing approach e2e tester action liz...

Download End To End Testing Kick Why End to End (E2E) Testing? E2E Testing Approach E2E Tester Action Liz Dietz

Post on 10-Aug-2020




0 download

Embed Size (px)


  • End To End Testing Kick Off November 15, 2018

  • Agenda

     UR Student and Workday Background

     Why End to End (E2E) Testing?

     E2E Testing Approach

     E2E Tester Action

     Liz Dietz • Vice President, Student Strategy and Product Management, Workday

    November 28, 2018 2/27

  • Project Org Chart

    November 28, 2018 3

    Why What Who When How

  • UR Student Information Website

     http://www.rochester.edu/urstudent/

    November 28, 2018 4

    Why What Who When How

  • Overview Of Scope

    Student Records & Curriculum Management Course Catalog | Programs of Study | Registration | Instruction

    Degree Audit | Transcripts | Reporting

    Academic Advising Cohorts | Advising | Academic plans | Credit Articulation

    Student Finance Charge Items | Charge Adjustment Schedules | Refunds | Payments and Payment Precedence | 1098-T | Financial Aid | Awards, waivers & grants

    11/28/2018 5

    Why What Who When How

  • Vision The University of Rochester envisions reliable, high quality student information systems and processes that will:

     Be flexible and extendable, accommodating current priorities and requirements, with the ability to evolve with changing and as yet unforeseen academic and administrative realities, such as new forms of assessment and outcome tracking

     Provide robust data capture and reporting capabilities, and verified, complete data to allow the University and our schools to better understand and support progress toward strategic goals, and the progress of our students toward their academic goals

     Provide a single, integrated source for core student data and services, and easier, real-time integration with ancillary and third- party systems

     Create a personalized system that provides users with the information and services they need, when and where they need it

     Result in configurable, reliable and automated processes for students, faculty and staff to achieve better outcomes with less effort

    November 28, 2018 6

    Why What Who When How

  • Guiding Principles  We will adopt common practices wherever possible to support a

    consistent experience; we will differ only where absolutely required

     We will structure data to improve our collective reporting and analytic capabilities

     We will automate activity and processes to enable staff to improve service for all our stakeholders

     We value integrated systems and processes over disparate systems and processes

     We will adapt administrative and academic practices as necessary to implement an effective solution

    November 28, 2018 7

    Why What Who When How

  • Project Phases

    November 28, 2018 8

    Why What Who When How

  • End to End Testing focuses on confirming the system works as designed

    • Does each task and business process function as expected for all key areas of functionality? Do all the features and functions of the process work correctly within that process?

    • Does the converted data ‘work’ in the application in the same way that data added directly to UR Student functions?

    • Do the processes ‘hang together’ correctly for a full system solution across business processes and functional areas?

    • Do the integrations load or extract data correctly to allow UR Student to interact with other campus systems? Critical integrations, especially those that load data, must be tested during the End to End testing window.

    • Do the reports provide the information necessary to support the process and/or users?

    • Testing to confirm End User security will be completed using Proxies and a series of user accounts identified for that purpose.

    Why End To End Testing?

    9November 28, 2018

    Why What Who When How

  • Testers Add Value  Testers evaluate functionality and data conversion

     Testers highlight changes to business processes and workflow/daily activity

     Testing follows the Agile methodology which is iterative • Testing an evolving product and process

     Testing identifies gaps • Needed fixes • Missing tasks • Current blockers • Workarounds • Parking lot • Change management

     Testers bring their knowledge and perspective

    • Expert knowledge of the system is actually a disadvantage during some testing

    • Testing helps define if the process and training is refined enough for casual users

     Testing ensures a smoother roll out/go live

     Testing scripts and feedback lead to training and documentation

    November 28, 2018 10

    Why What Who When How

  •  E2E tests tasks and business processes from beginning to end

     E2E testing is NOT the final test

     Additional Workday functionality will be released after E2E

     Day in the Life (DIL) testing follows

    • DIL testing is structured around typical roles rather than business processes

    - Instructor, Advisor, Registrar, Curriculum Manager, Department Coordinator, Student

    Where E2E Falls in the Project Plan

    11November 28, 2018

    Why What Who When How


    Kickoff E2E Testing


    WD’s special UR release


    WD32 Preview

    Feb / Mar

    Kickoff DIL Testing

    May ‘19

    Go/No-go Decision


    Phase I Target




  • Community Testers

    November 28, 2018 13


    John Hain Logan Hazen Vicki Aspridy Andrea Chamberlain Tracy Pezzimenti Kathleen Kelly Linda Lipani

    Terry Magee Kim Starken(Slate) Amy McNiven Nancy Kita Erica West Elaine Maholick

    Jenne LaPlaca Wendy Cellini Andrew Smagin

    Christina Crispin Pam Kaptein Robin Cooley

    Robert Bones Claire Urbanowicz Jason Buitrago

    Jenni Watson (ECMS) Pam Black-Colton

    John Ballou Lisa Norwood Britt Semenow Pam Black-Colton Jason Buitrago

    Kate McKenna Kelly Johnson Caroline Sonett Jon Ramsey

    Liz Monte

    Cheryl Ernst

    Andy Dillenbeck Tim Woodward Jennifer Horn Tracy Korts Brian Donovan Tammy Terrana Jeff Bloss n/a Mike Winter



    Individuals noted in blue will be validating downstream Finance functions.

    Jen Baker, Cindy Cheng, Jim Dobbertin, Marta Herman, Lisa Mekeel, Kate Nguyen, Shannon Ozkum, Marge Schwartz, Jeff Sullivan








    Aid Mandi Lacey, Carrie Welch

    Kathy Blackmon, Nancy Anderson, Joe Brown, Karim Yaport, Abby Mansoor

    Jeff White

    Nicholas Smith

    Katie Mead

    Janina Koszela

    Peg Ehmann, Nancy Ducci

    Why What Who When How

  • The Role Of The Community Tester

     Functionality and Data Validation tested separately

     Community Testers will work with a functional testing liaison from project core team

     Test instructions will be provided

     Complete tests in a timely manner

     Test lab space provided

     Provide results on scenario spreadsheet to liaison at the end of each test day

     Offer insights

     UR Student Ambassador to broader UR community

    November 28, 2018 14

    Why What Who When How

  • Testing Schedule

    Proposed Initial Schedule - Sign up sheets available today

    November 28, 2018 15

    Why What Who When How

    Monday Tuesday Wednesday Thursday Friday

    26-Nov 27-Nov 28-Nov 29-Nov 30-Nov

    Morning - Harkness 114 SR - Function SF

    Afternoon - Scottsville Rd 330 AA SR - Data SR - Data SF AA

    3-Dec 4-Dec 5-Dec 6-Dec 7-Dec

    Morning - Harkness 114 SR - Function

    Afternoon - Scottsville Rd 330 SR - Function SF AA SF AA

    AA - Academic Advising

    SF - Student Finance & Financial Aid

    SR - Student Records & Curriculum Mgmt

    Key Testing Dates End 2 End Tests: Nov 2018 – Jan 2019 Day In Life Tests: Feb 2019 – March 2019

  • Test “Packet”

    Test “Packet”

    Functional Test Input

     Testers will receive inputs to provide information to complete the test:

    November 28, 2018 16

    Test “Packet”

    Test Scenario

    Test Script

    Test Data Sheet

    Related functionality to test as a unit One or more per Rochester Business Process

    Defines the specific test cases that should be executed to fully test the business process/functionality w/expected result

    Describes the specific steps to be taken in UR Student to complete the test case(s)

    Defines the data to be used (e.g., entering multiple applications, completing registration for multiple students, adding charges or making payments on multiple students, etc.)




    Rochester Business Process

    Why What Who When How

  • Security Role Evolution

     Security setup for testing is a starting point and may shift

     Modifications to security will be needed over time

     Testers may be in different roles with different security during testing

    November 28, 2018 17

    Why W


View more >