Workday@Yale ISR Process Overview
This document outlines the system integration testing process for Workday@Yale Release 4 Impacted System Remediation (ISR) Forum. It covers terminology, test schedule, integration testing phases, and overall test schedule for 2016-2017. The content includes detailed timelines, processes, and key activities related to SIT, ISR, UAT, regression testing, and more.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Workday@Yale Release 4 Impacted System Remediation (ISR) Forum: System Integration Testing December 5, 2016 - 1 -
Agenda Terminology Test Schedule ISR Integration Testing Process ISR Checklist ISR Integration Testing Calendar Next Steps Questions - 2 -
Terminology Workday Systems Integration Test (SIT) (11/1- 1/20) Workday tests their business processes, ensures integrations are functioning (may be done with a small number of systems), and that Workday is functioning. See https://workday.yale.edu/system- integration-testing-sit for more detailed definition. Impacted Systems Remediation (ISR) Integration Test (1/21 3/31) Impacted systems test their systems with Workday ensuring that integrations are bi-directionally functional, that transactions are appropriately generated, submitted, processed, and the results confirmed. Regression Test (2/17-4/17) The process of selective retesting of systems and system components to verify that changes made to the system due to configuration changes and/or Workday updates have not caused unintended effects and/or to identify the impact of the change. Additionally to ensure environment stability in preparation for User Acceptance Testing level. https://workday.yale.edu/regression-testing User Acceptance Test (UAT) (4/17-5/17) The process of completing the final validation of required business functions and flow of the system by end users based on business requirements. It is also an opportunity for the project to engage additional sets of end users in the project prior to deployment and test the effectiveness of the training and documentation. https://workday.yale.edu/user-acceptance-testing-uat#overlay- context=testing-workstream - 3 -
Overall Test Schedule 2016 2017 28 27 Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Test Planning 6/20/16 8/30/16 Go-Live 1 SIT Kick-Off SIT Execution 10/26/16 1/20/17 SIT Prep 9/7/16 10/04/16 ISR Integration Test Execution 1/31 3/31 ISR Integration Test Prep 10/16 12/16 UAT Kick-Off Performance Prep Cycle 1 1/1/17 1/31/17 UAT Prep 3/20/17 4/7/17 UAT Execution 4/10/17 5/18/17 Regression Prep 1/23/17 2/24/17 Regression Execution 1/23/17 4/6/17 Test Planning 8/16 9/16 Payroll Costing Compare Execution 4/10/17 5/18/17 Performance Execution Cycle 2 2/16/17 3/21/17 Performance Execution Cycle 1 11/17 1/17 Performance Prep Cycle 2 1/23/17 2/15/17 FDM Converter PANDA GAP App Delivery 8/1/16 1/23/17 FDM Validator Group 4 Group 2 Group 7 / Group 8 Group 6 Group 9 Group 1 Group 5 Group 3 Group 10 Integrations Delivery 11/2/15 3/11/17 P2 SIT HCM & Reports UAT FIN & HCM Report Delivery 12/14/15 3/7/17 WD27 Planning 6/2016 8/2016 WD27 Execution 8/2016 9/2016 WD28 Planning 12/2016 2/2017 WD28 Execution 2/2017 3/2017 - 4 -
Integration Testing - 5 -
ISR Test Roles & Responsibilities Stakeholders involved in the defect management process should be aware of their respective roles and responsibilities, as indicated below, to ensure that key activities within the defect management process are accounted for. Roles General Responsibilities Execute test cases Raise issues and document defects found during testing Communicate upstream and downstream defect consequences Proactively participate in defect triage meetings and track defect status System Owner Tester Review the defects logged for validity and severity Report the defect status on a daily basis to Test Lead Coordinate the execution of daily scheduled test events Coordinate defect triage meetings and monitor defect resolution progress Quality Assurance (QA) Support System Owner Testers with defining and documenting defects Responsible for overseeing defect fix progress among Test team, Technical team, and Functional team Manage ALM test execution and defect status for respective ISR system Proactively participate in defect triage meetings and tracking defect status Impacted Systems Remediation Point of Contact (ISR POC) Support execution and validation of test scenarios Review, fix, and/or reject defects Proactively participate in defect triage meetings and tracking defect status Technical / Functional Support Teams - 6 -
ISR Test Process Flow ISR POC System Owner / Tester QA Technical/ Functional Support Teams 1 Provide guidelines, templates, and a test plan 2 Validate test plan and create test scenarios 3 Set up scenarios in the test tracking tool 4 Review pre-test checklist to ensure readiness Provide support 5 Provide support Execute test case and verify results Provide support 6 Record defects/updates in the defect reporting tool/template Assist with capturing and defining defects 7 Manage defect triage and tracking tool updates Participate in defect triage process Participate in defect triage process Participate in defect triage process 8 Re-execute until no critical defects remain identified Collaboration among the different parties will enable a fully integrated testing environment that will mimic the real world use of each impacted system. - 7 -
ISR Test Scenario System Name Category Test Scenario Name Test Scenario Description Step # Step Description (Action) 1 Connect to MFT server Expected Outcome Tester Name <System Name> MFT Integration <integration_name> - inbound Validation of full end-to-end processing for Inbound (in reference to workday) integrations Successfully connect to MFT server using system specific user_id and password accounts <User Name> 2 Upload file to MFT server System successfully generated file and uploaded file to correct MFT location. Integration initiates succesfully, locates file in MFT location, and download file successfully. 3 WD integration locates and downloads file 4 WD integration consumes file Validate data consumed Integration procesess file as per requirements. Functional team runs report for System Owner to validate WD consumed data correctly. 5 KEY TERMS: Category: Identifies the integration type that the scenario will be testing (i.e. MFT vs. Web Service) Test Scenario Name: Refers to the scenario the tester is executing, designed specifically to test an integration with Workday. As a convention, Name refers to the integration being tested. Description identifies the objective of the test scenario. Test Scenario Description: Lists the actions the tester needs to sequentially perform in order to complete the scenario. Expected Outcome: The expected result after executing the step. - 8 -
ISR Test Defect Management The preferred practice is for system owners to directly access the test management tool, HP ALM, to record and manage their test scenarios and defects throughout the test lifecycle. Process Daily Defect Review Meetings New ticket review beginning with the most critical issues Aging defects review beginning with the most critical issues Open questions and requests for assistance Defect Tracking Unexpected results discussed between the System Tester and the ISR PoC to confirm validity Preference is for System Tester to self track defects and test execution in the HP ALM tool. Training provided as needed. If the preferred method is not possible, the System Tester records defect in defect template (example shown next slide), submits via email to ISR POC who inputs into ALM and tracks and defects. Resolution Management System Owners/Testers in conjunction with Functional/Technical Workday resources are expected to manage the resolution of defects. The ISR PoC and Workday QA resources will assist in the coordination of resources and overall management of issues in order to remove roadblocks and ensure timely resolution of issues. - 9 -
Defect Submission: Email System Under Test System Name Yale department name Department The name and NetID of the person who reported the defect. Reported By Summary of the defect. Keep this clear and concise. Summary Description Detailed description of the defect. Describe as much as possible but without repeating anything or using complex words. Keep it simple but comprehensive. Step by step description of the way to reproduce the defect. Number the steps. Steps to Replicate The actual result you received when you followed the steps. Actual Result The expected results. Expected Results Attach any additional information like screenshots and logs. Attachments Any additional comments on the defect. Remarks Defect Severity Severity of the Defect. Critical This defect has caused all further processing to be suspended. There is no work around. The problem must be corrected for the project to be successful. High - This defect has caused a serious problem in system processing. There may be a workaround, but it would result in additional work. The problem should be corrected for the project to be successful Medium - A problem that does not inhibit testing from continuing with relatively straightforward workarounds and/or has a minor impact on the business ability to use the application. Does not need to be fixed before go-live but requires signoff by the business of the known issue before go-live. Low - This defect does not cause a significant user or processing problem. Typically it would be deferred until after a release to production. - 10 -
ISR Test Checklist Area Entry Criteria Exit Criteria Testing Plan signed off and communicated Defect tracking established Test Lead conducts SIT kickoff meeting Program Office signs off on test results and action plan Test Lead conducts exit meeting WD ISR / QA Impacted System Unit Test is complete Test scenarios are documented Test data set is defined Scenarios and data sets have been provided to QA (cc. ISR PoC) Identify System Testers and confirm availability on the planned SIT date Check access to MFT test environment (https://securetransfer- tst.its.yale.edu/ebiz/hop7/yugl/jsa/ source , where source will be different for each system) Check ability to interface Web Services, if applicable. If you are unsure, please reach out to ISR PoC to get connected to your technical resource. All blocker and critical defects have been fixed, retested and passed. 100% of all tests are executed with 95% pass rate. All defects are reported in the defect tracking system. Workarounds have been secured for any defects still in open status. System Owners All relevant roles have been tested. All results documented in test results and any necessary action plans Roles identified and configured Logon IDs and passwords created WD Technical Resources - 11 -
ISR Test Calendar December January Nov Dec 5 Jan 10 Jan 11 Jan 30 Dec 12 Chemistry Billing IDR YARDI GSPS EHS Integrator Voyager Morris Sierra EPIC Hopper (Donors) FAMIS Serengeti PCS LOTIS - 12 -
Next Steps If you are a wave 1 (WD SIT) System owner: Work closely with your ISR POC to ensure a shared understanding of your current status Attend to any outstanding items on the ISR Test Checklist (slide 12) Execute your test scenarios as planned Keep your ISR POC in the loop on any updates or new developments If you are a wave 2 or 3 System owner: Get with your ISR POC to ensure your test dates are clearly understood & mutually agreed upon Review the ISR Test Checklist (slide 12) to ensure your test readiness Start constructing your test scenarios Determine who your tester will be and whether you need training on the HP ALM tool Keep your ISR POC in the loop on any updates or new developments - 13 -
QUESTIONS - 14 -
