Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
Parallel Test Approach
I.
Introduction
The purpose of this document is to explain the approach that will be used for a Parallel
Test phase of the University of Michigan HE Upgrade Project. This document outlines
the following:

Parallel Test objectives and scope

Parallel Test comparison tools

Parallel Test entry and exit criteria

Parallel Test calendar

Parallel Test team

Parallel Test issues and risks

Parallel Test issue resolution process

Parallel Test assumptions
II. Parallel Test Approach
A. Objectives
The primary objective of Parallel Test is to identify discrepancies in the Gross-to-Net
calculation between versions of Michigan’s PeopleSoft system. All data will have been
entered using the PeopleSoft system and will have been converted into the Parallel
environment via the conversion script to be used for production implementation (no
conversion from legacy data is required).
Table 1 includes the components of the gross to net calculation that may cause
discrepancies between paychecks created in the v7 PeopleSoft Payroll System and
paychecks created in the v8 PeopleSoft Payroll System. The parallel testing process tests
these components and resolves any discrepancies between the two. Resolutions may
come in the form of:
 Updating software configuration
 Correction of work units (e.g. fixing custom programs that impact gross-to-net)
 PeopleSoft correcting delivered source code
 Correcting data conversion scripts
 Explaining and accepting the discrepancy.
Document1
Page 1 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
Other normal biweekly and monthly processes will be run and results checked, but will
not be compared against production data. E.g. Paycheck distribution, gross pay register,
G/L interface, leave accrual, etc.
Table 1
Gross Earning Calculations – verifying the employee’s gross earnings tests the following:
 delivered/upgraded gross earning calculation routines correctly calculate an
employee’s gross pay
 modified/custom gross earning calculation routines correctly calculate an
employee’s gross pay
 earnings table is set up correctly
Deduction and Garnishment Calculations – verifying the employee’s deductions and
garnishments tests the following:
 delivered/upgraded deduction and garnishment calculation routines correctly
calculate all types of deductions (e.g., before tax, after tax, employer paid, etc)
 modified/custom deduction and garnishment calculation routines correctly calculate
all types of deductions
 deduction table is set up correctly
 garnishment rule and disposable earning definition tables are set up correctly
 benefit plans and benefit programs are set up correctly
Tax Calculations – verifying the employee’s taxes tests the following:
 delivered/upgraded tax calculation routines correctly calculate federal, state, and
local taxes
 modified/custom tax calculation routines correctly calculate federal, state, and local
taxes
 federal, state, and local tax tables are setup correctly
Time & Labor – verifying the loaded time data tests the following
 delivered/upgraded Time Admin process correctly loads time into the system
 modified/custom Time Load Interface correctly loads time into the system
B. Scope
In order to fully test Michigan’s Gross-Net-Calculation for both of its pay frequencies,
five separate parallel tests will be executed. Parallel testing uses historical payroll data
from the current version of the PeopleSoft Payroll System. In other words, prior to the
start of parallel test, the pay periods have already been processed in the Payroll System.
First, this allows the parallel test team to extract the historical payroll data and prepare it
for comparison to PeopleSoft data without interfering with the current production
system’s operations. Second, flexibility is built into the parallel test schedule because it
is not dependent on the production system’s payroll processing schedule.
Document1
Page 2 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
The parallel test will not test each employee in the system, since doing so would require
replication of manual keypunching done by timekeepers. Instead, a cross-section of
employees has been chosen, which will include most of the University’s employees. The
employees in parallel test will meet one of the following conditions:
1) Loads to Time and Labor via interface file (including Corpay – scanned
timesheets, as well as interfacing departments).
2) Does not exist in Time and Labor.
3) Is in workgroup PAEXHOSP. This workgroup includes many MPP employees,
most of which are not eligible for TRCs such as Overtime or Shift, which would
affect their Net Pay. Even though their time will not be loaded into Time and
Labor, this should not affect their pay.
The Parallel Test will load Convenience Deduction data. Cycle 4 will include manual
changes made to paysheets, since Payroll Office staff will perform dual entry for these
changes in the Cycle 4 parallel tests. BWR employees will only be tested in Cycle 1.
Prior Period adjustments will not be tested in Parallel test; they will be included in
System Test. System Test will also test keypunch data entry through the payroll cycle.
HE 8.0 Upgrade Parallel Test Scope
Cycle 1
Time files
Document1
Time Load
Interface
Time Admin
appengine
Paysheet
Paycalc
G/L Interface
Sponsored
Research
Page 3 of 13
Cycles 2, 3, 4
Pay
Confirm
Last Updated -
2/9/16
Print
Paychecks
Direct
Deposit
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
C. Parallel Test Cycles: The following test cycles have been defined for
Parallel Testing
o Cycle 0 – Mock Parallel
 Verify that PARA(for new PS version) has been setup correctly,
and that programs/tables/data have been migrated completely.
Data will not be reconciled at this point.

o
o
o
o
Document1
Should be completed prior to “real” start of Parallel Test.
Cycle 1 – Biweekly without Time Load

XX/XX/XX pay period end date

Based on date of production cut of data, Time WILL already have
been loaded into payroll; so custom Time interface WILL NOT
need to be run.

Verify that Payroll-only functionality has not been adversely
affected by upgrade.
Cycle 2 – Biweekly with Time Load
 XX/XX/XX pay period end date

Based on date of production cut of data, Time will NOT have been
loaded into payroll; so custom Time interface WILL be run.

Verify that T&L functionality, in addition to payroll, has not been
adversely affected by upgrade.
Cycle 3 – Monthly with Time Load

XX/XX/XX pay period end date

Based on date of production cut of data, Time will NOT have been
loaded into payroll; so custom Time interface WILL be run.

Includes G/L interface, and sponsored research.

Verify that the upgrade did not adversely affect Monthly pay
processing.
Cycle 4 – AFTER NEW CUT OF PRODUCTION DATA (from XX/XX/XX
to XX/XX/XX) AVAILABLE

Re-run Cycle 2 (Biweekly with Time Load) for XX/XX/XX pay
end date for Biweekly

Re-run Cycle 3 (Monthly with Time Load) for XX/XX/XX pay
end date for Monthly

Central Payroll and Hospital Payroll offices to assist in reviewing
and verifying results.
Page 4 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
D. Parallel Test Comparison Tools
The Parallel Test Comparison Toolset is a set of PeopleSoft queries, on-line objects, and
SQR’s that compare the Gross-to-Net calculation between v7 PeopleSoft Payroll system
and v8 PeopleSoft Payroll system. These queries, on-line objects, and SQR’s will be
created during the Parallel Test Planning and Prep phases to meet Michigan’s
requirements. A DB Link between the Production environment and Parallel
environment will be created for this purpose.
There following Parallel Test Comparison Tools created for this effort:

Check Payable Time Query

Gross to Net Comparison Report with Earnings/Deductions/Taxes Detail
Check Payable Time Query
This query will validate the data in TL_Payable_Time (V8) against the Tl_Empl_Dlyerns
and Tl_Empl_Dlysum (V7) after the Time Administration and Load Time and Labor is
run. This Query will print only the discrepancies between V8 and V76 data into an Excel
Spread Sheet. This will help isolate data errors resulting from the Time & Labor process,
which can then be corrected prior to the start of payroll processing.
Gross to Net Comparison Report
This SQR will create a detailed comparison report of the differences between v8 and v7.
The program will first compare the net pay amounts in each system. If a discrepancy
exists, total earnings, total deductions and total taxes will then be compared. If either of
those components does not match in both environments, a detailed listing of records will
be written from each system. The resulting report will be an Excel spreadsheet to allow
for quick and easy sorting and searching and resolving discrepancies.
The following fields (order TBD) will be included:
Employee ID
Paygroup
Department Code
Pay Period Begin and End Dates
Total Earnings, Deductions, Taxes, Gross Pay, Net Pay from v8
Total Earnings, Deductions, Taxes, Gross Pay, Net Pay from v7
Total Earnings, Deductions, Taxes, Gross Pay, Net Pay Differences
Earnings Detail
The following fields (order TBD) will be included:
Employee ID
Paygroup
Department Code
Pay Period Begin and End Dates
Document1
Page 5 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
Earning Codes and Amounts Differences between v8 and v7
Deduction Detail
The following fields (order TBD) will be included:
Employee ID
Paygroup
Department Code
Pay Period Begin and End Dates
Deduction Codes and Amount Differences between v8 and v7
Tax Detail
The following fields (order TBD) will be included:
Employee ID
Department Code
Pay Period Begin and End Dates
Tax Codes and Amount Differences between v8 and v7
Document1
Page 6 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
E. Entry and Exit Criteria
Parallel test entry criteria define the tasks that must be satisfied before parallel testing
can be efficiently executed. Parallel test exit criteria define the successful conclusion of
the parallel testing stage.
Entry Criteria
If one or many of these tasks are not complete, parallel test can not begin and the start
date will be delayed which may delay the parallel test completion date and ultimately
the overall conversion date. Table 2 defines the parallel test entry criteria.
Table 2
1) The Parallel Test environment is established for sole purpose of parallel test and includes all
custom objects.
2) The control tables are loaded into the parallel test environment.
3) Potential “CPU-hog” programs have been tuned to run as efficiently as possible: Interface
Load Time, Time Admin, etc.
4) The parallel test team members have been identified and have dedicated time to work on
the parallel test effort.
5) The parallel test team has access to the TI Resolution team. Discrepancies will arise that
require PeopleSoft COBOL, SQR, and Online knowledge and fixes need to be completed in a
timely fashion to keep parallel test on schedule.
Exit Criteria
Parallel test is not complete until all of the exit criteria have been satisfied. If any of the
parallel test exit criteria are not satisfied, unexplained discrepancies may exist in the
parallel test employee population’s gross to net calculation. As a result, the parallel test
team will not have the data that it needs to contribute to the “go live” decision. Table 3
defines the parallel test exit criteria.
Table 3
1) All discrepancies have been explained or corrected, and documented.
2) All earnings calculation discrepancies have been explained or corrected, and documented:
3) All deduction and garnishment calculation discrepancies have been explained or corrected
and documented.
4) All tax calculation discrepancies have been explained or corrected and documented.
Document1
Page 7 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
F. Parallel Test Calendar
The parallel test calendar shows the cycles and schedule (HE 8.0 Upgrade Parallel Test Schedule.xls)
5/26
6/2
6/9
6/16
6/23
6/30
7/7
7/14
7/21
7/28
8/4
8/11
8/18
8/25
9/1
9/8
9/15
9/22
9/29
10/6 10/13 10/20 10/27
11/3 11/10 11/17
MOCK PARALLEL - 3 wks
biweekly, monthly, time load
REFRESH ENVIRONMENT
CYCLE 1 - 3 wks
12/27/02 biweekly, no time load
CYCLE 2 - 3 wks
1/10/03 biweekly + time load
Apply Tax Update 02-G
CYCLE 3 - 3 wks
1/31/03 monthly + time load, G/L, sponsored research
TEST MOVE #3, new data from 7/31/03 for Parallel Test
Parallel Resources move to Systest
Apply Tax Updates thru 7/31 Prod
CYCLE 4.2 - 3 wks
re-run cycle 2 for 8/8/03 biweekly
CYCLE 4.3 - 3 wks
re-run cycle 3 for 8/31/03 monthly
Apply remaining Tax Updates
Document1
Page 8 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
G. Team Structure
The following chart lists the team members who will be involved in the Parallel Test.
The product managers of each area (1st row listed) will have the final say in how a
discrepancy is to be resolved or explained, with Scot having ultimate signoff.
We would like to have Central Payroll and Hospital Payroll offices involved in
reviewing and verifying results during the Parallel Test phase. Our goal is involve these
groups during Cycle 4 at the latest.
Payroll/Time & Labor: Scot Yoas, Carrie Shumaker, Ruby Nugent, Arun Madadi,
Nancy Goff, Kristin Lorenz, Dave Jamison, TBD Parallel Consultant; all PYTL team
members will be on the TI Resolution team.
Benefits: Denise Stegall, Amy Lawrence
Human Resources: Judy Aldrich, Val VanHaaften
Campus Community: Karen Kuffner, backup
Higher Education: as needed
Payroll Office: as needed
Hospital Payroll: as needed
Document1
Page 9 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
III. Status and Reporting Metrics
A. Defect Tracking Approach
During all phases of system testing, defects will be logged into the Lotus Notes Testing
Incidents database, including performance tuning needs. The database will provide the
necessary information for developers, as well as provide management with reports. The
developers need the name of the reviewer, date discovered, the requirements, test case
id, severity code, and any other relevant information. All high and medium priority
issues must be resolved or have a work-around in place to go-live. To ensure timely
resolution of cases submitted to PeopleSoft during the system test phase, the SIT lead
will be provided a contact at PeopleSoft.
B. System Test Phase Tracking Approach – Metrics To Utilize
System test will be tracked by phase and within each phase the business processes by
module. Leads will be responsible for ensuring that time is entered into Planview and
all stats are reported to the system test phase lead in a timely manner. The format of the
status reports being utilized for design and development will be used for system testing,
as well as the reusable test plan reports. There may be additional reporting
requirements, as well as, the CPUs may have additional detailed reports.
Metrics that will be tracked include but are not limited to:
1. Number of conditions, by priority (ABC), that are in progress, in error, passed,
deferred, or not started.
2. Percentage of conditions tested.
3. Percentage of conditions passed.
4. Percentage of A, B, and C conditions. (Including % of each priority that has been
tested and passed.)
5. What cycle/sub-cycle the conditions are in.
6. Total number of conditions per cycle/sub-cycle.
7. Total number of conditions per priority.
8. Percentage of Effort Complete
9. Percentage of Effort Earned.
10. Percentage of Effort Remaining.
11. Number of Open Testing Incidents – by priority.
Document1
Page 10 of 13
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
C. System Test Status/Issues Meeting
During system testing, it is recommended that a weekly status meeting be held at the
same scheduled time on the same day each week. This meeting will support a
communication process to inform the project team on the testing status, problems or
issues, and changes. The Agenda will include a review of open high and medium
issues, the overall system test plan, and any action items from the previous week.
Meeting minutes should be taken that include a list of attendees, discussion points, and
action items. Developers and reviewers should be represented in the meeting, as
needed.
IV. Assumptions, Issues, and Risks for Parallel Test
Approach
A. Assumptions
The following assumptions have been made regarding this Parallel Test:
1. The Time and Labor portion of the test will begin with the Interface Time Load,
not with files being sent from vendors.
2. Manual entry will not be done. Only the employees coming through the time
files will be parallel tested.
3. Parallel Test needs to be supported like a production system – with quick
turnaround time from all supporting teams (functional and technical).
Turnaround time for all requests must be less than 24 hours.
4. The Parallel Test team will approve all migrations into the Parallel environment
prior to the move. This is needed so that migrations do not interrupt a paycalc
(or other process) that is in progress. This has been raised to the STAT project
team to include a workflow specifically for Parallel Test.
5. Cut of Parallel Test data already has 12/27/02 pay end date time loaded.
B. Issues and Risks
The table below lists the issues and risks associated with the University of Michigan
Parallel Test. Accompanying each issue is an associated risk if an individual issue is not
resolved.
Issue
Document1
Page 11 of 13
Risk
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
Issue
Risk
Parallel Test and System Test
1.
schedules completely overlap
(both are scheduled to start in
June), with Mock Parallel
preceding System Test by a few
weeks.
Parallel test is executed in its
2.
own environment. If this
environment is not set up or
configured correctly, parallel
test can not start on time.
The control tables need to be
3.
loaded into the parallel test
environment.
Parallel test team members with
4.
the prerequisite skills and
knowledge need to be identified
and be dedicated to the parallel
test effort.
The parallel test team needs
5.
access to the Fix-It team.
Discrepancies will arise that
require PeopleSoft knowledge
and fixes need to be completed
in a timely fashion to keep
parallel test on schedule.
The parallel test team may spend time investigating
discrepancies that result from problems that should have
been identified and fixed during system test.
Document1
Page 12 of 13
Any other use of the environment being used for parallel
test will impede the progress of parallel test.
Parallel test can not begin until the payroll and benefits
control tables are loaded into the parallel test
environment.
If the parallel test team is not a full time dedicated team,
the parallel test may not be complete before the decision
needs to be made as to the status of the “go live” date.
If the TIs that result from parallel test are not fixed in a
timely manner, the parallel test may not be complete
before the decision needs to be made as to the status of
the “go live” date.
Last Updated -
2/9/16
Information and Technology Services
PeopleSoft Upgrade Project
M 5000A2 – Parallel Test Approach Document
C. Issue Resolution Processes
In order for the Parallel Test execution to run as smoothly as possible, and the resources
to be used as effectively as possible, the following processes should be followed when
issues arise:
Functional Issue Escalation
When issues that cross functional teams arise, notify Scot, and then call primary, if no
answer, call secondary. Follow-up with email to both, .cc Scot. If data changes need to
be made to any environment, a TI should be created for that request.
Technical Issues
When technical issues arise (e.g. programs not running, version control, etc.) the TO
group will be notified via standard procedures. Email during business hours, call 3-4000
during off-hours. The only difference is that the PARA8 environment will be supported
at a higher-level than standard testing environments (see Assumptions).
Migration Requests
Migration requests will follow the standard OMR/STAT procedure. The only difference
being that a Parallel Test team member will approve all migrations into the environment
prior to the actual move. (See Assumptions)
V. Deliverables

Work Breakdown Structure (WBS) - updated business processes and adjusted
hours. This is required at the beginning of the system test phase, in order to put
the WBS into planview for tracking and reporting.

M571 – System Test Plan
o
Master reusable test plan (RTPs) with appropriate rating scale assigned to
each business process.
o
Test scripts and process flows as necessary
o
All internal and external touch points/interfaces and key contacts must
be identified.

STAT - OMR

TI (Testing Instance) Database (Resolution of issues or work around in place)

M539 – Parallel Test Status Report
Document1
Page 13 of 13
Last Updated -
2/9/16