Introduction:
Parallel Testing is the most complex part of HRIS/payroll implementation. Due to the complexity and crucial importance of Parallel Testing this article goes into considerable detail to assist the reader with understanding, planning and executing Parallel Testing.
The article is the second of a two part series explaining everything you wanted to know about Parallel Testing - but were afraid to ask. Part 1 of the article defined exactly what Parallel Testing is. It then focused on key considerations when planning for a Parallel Test. This article, “Part 2”, takes the reader through each phase of Parallel Testing. The objective of each phase is explained and tips for maximising project effectiveness that can be found in each Parallel Test phase are provided. For Part 1 of this article, please go to the following link (https://www.comparehris.com/payroll-software-parallel-testing-/). For Part 2, please keep reading.
Phases of Parallel Testing:
This article explains the phases that make up the Parallel Test of a HRIS/payroll implementation. It provides tips on ways to maximise project effectiveness specific to each phase of Parallel Testing. The article discusses the following phases of Parallel Testing:
1. Prepare the Parallel Test Environment
2. Input the parallel test data for the pay cycle
3. Run the payroll engine
4. Compare outputs and manage discrepancies
5. Commit the payroll
6. Repeat steps 2 – 6 (if required, for additional pay cycles)
7. Test additional payroll outputs
8. Present results to stake holders/steering committee
Phase 1: Prepare the Parallel Test Environment
Explanation:
Parallel Testing begins with preparing the Parallel Test environment for data entry. To do this, the project team will take the snapshot of the legacy database and use it to populate the new system using data conversion scripts. This will ensure that when data is being input for the Parallel Test, it is exactly the same data being entered as it was done in production.
Dependencies for commencing Parallel Testing by executing this sub-phase are:
• The new system must be configured (and customised, if required) according to the business requirements of the organization implementing the HRIS/ payroll system.
• Some form of “pre-testing” should have been conducted. Generally this testing can be termed “functional” or “application” testing. This test will test key functional business requirements using test data. The objective of this test will be to ensure that the configurations and customisations made to the system are functioning as expected.
• A “snapshot” has been taken of the legacy database at the appropriate time
• conversion scripts have been adequately tested
Once these 4 prerequisites have been successfully achieved, the project team will be ready to prepare the Parallel Test environment.
Tips:
The tasks in this phase mirror closely the tasks executed when the project “goes live”. Hence, this phase of Parallel Testing provides an excellent opportunity to rehearse these elements of the go live effort.
The project team should try to convert the data and install it into the new system in the timeframes required during the go live. Lessons learned during Parallel Testing can then be applied to the go live plan.
Phase 2: Input the parallel test data for the pay cycle
Explanation:
In this phase, all the input data of the pay cycle being Parallel Tested will be entered into the new system. For more information about selecting pay cycles and reserving input data, please refer to part 1 of this article: Payroll Software Parallel Testing, part 1 of a 2 part series
This phase is dependent upon the data being available as well as upon the environment being ready.
Tips:
During this phase, users will have their first chance to see the new system populated with actual production data. Often, this makes the new system seem a lot more “real” than when test data was being used. As such, it is important to ensure that the people who enter the data during this phase are those who will use the system post go live.
With careful planning and communication to the data entry resources, this part of Parallel Testing can substitute, or augment, User Acceptance Testing and training. Parallel Testing provides an excellent opportunity for making production transactions on production data, but in a safer environment than production. This will contribute to users being much more confident as the first time the transaction needs to be done post go live. Therefore, each data entry resource should have an opportunity to enter as many types of transactions as possible. Furthermore, it is advisable to incorporate time into the plan to take feedback from the data entry resources about ways in which the system or associated processes could be improved.
Phase 3: Run the payroll engine
Explanation:
This phase simply involves running the payroll engine, or calculator, over the data from the selected pay cycle in “non-update” or “non-commit” mode. There will, most likely, be several “iterations” of this step. This will be especially so when Parallel Testing the first pay cycle. The first pay cycle of Parallel Testing is often marred by many data entry and business rule configuration errors.
Tips:
This phase can also be a “dress rehearsal” for when the project goes live. Often, this part of the process will be done by the vendor post go live. If this is the case, then do not waste time getting involved in it during Parallel Testing. Rather, ensure that whatever processes and “hand-offs” to be used after go live are trailed during this phase of Parallel Testing. Any “bumps” in the process should be identified and addressed before the system goes live.
Phase 4: Compare outputs and manage discrepancies:
Explanation:
Once the payroll engine has been run and output files have been produced, the outputs of the new system will need to be compared with the outputs reserved from the legacy system.
Any discrepancy between the parallel and legacy file, no matter how small, must be explained. Furthermore, the explanation must be acceptable in terms of risk posed to the accuracy of the payroll.
It is likely that there will be several iterations of running the payroll engine and comparing the outputs as discrepancies are identified and explained. Often discrepancies will be due to data entry errors or errors in business rule configurations. Thus, throughout the iterations of this phase, adjustments will be made to configured business rules and users will become more familiar with how to correctly use the system and enter data.
Tips:
This Parallel Test phase is a great opportunity to consolidate users’ knowledge of how to accurately and effectively use the system. Make sure that defects due to incorrect data entry are not simply re-entered in order to get through the Parallel Test as fast as possible. Take the time to ensure that users understand why and how the data entry error caused the miscalculation. Share the learning with all users and update user guides/training documentation, if required.
Phase 5: Commit the payroll:
Explanation:
Once the threshold for accuracy has been achieved for the pay cycle you are Parallel Testing, commit the payroll. (i.e. run it in “update” mode).
Tips:
If you are testing consecutive pay cycles, then committing the payroll will in effect prepare the environment for the pay cycle. No additional work will be required to prepare the Parallel Test environment for the second Parallel cycle.
Phase 6: Repeat steps 2 – 6 (if required for additional cycles)
Explanation:
For subsequent pay cycles being Parallel Tested, you will need to repeat phases 2 - 6. Generally, testing two pay cycles proves that the new system is calculating pays within an acceptable parameter of accuracy.
Phase 7: Test additional payroll outputs
Explanation:
In addition to salaries, other payroll outputs should also be subject to Parallel Testing. Examples of additional payroll outputs are: tax department input files; any files which need to go to retirement fund contribution bodies (e.g. superannuation clearing houses); the disbursement files which need to go to the bank; the files which will write to the company GL.
The “test” of these files is two-fold: First, it is important to ensure that the discrepancies between these files and the files reserved from the legacy system are acceptable. Second, it is advisable to work with the recipients of these files to ensure that they can be uploaded and read in the recipients’ system.
Tips:
Generally, the testing of other files is simpler than salary files. As such, it is advisable to focus on salaries in the first Parallel Cycle and then introduce these elements in the second Parallel Cycle.
Liaising with third parties for this type of test can be time consuming and bureaucratic. It is advisable to start discussion with recipient bodies (especially banks) as soon in the project life cycle as possible. This will ensure that when the files are produced the process for recipient entities to test the uploading of files is clear.
If the upload test fails or it is not possible to test the file uploads within the Parallel Test time frames, risk mitigations should be thoroughly considered before suggesting a delay to the go live. An example of a risk mitigation to consider is whether a manual transfer would be possible should there be a risk that the automatic file transfer not be available immediately after go live.
Phase 8: Present results to stakeholders/steering committee
Explanation:
Once the requisite number of pay cycles has been Parallel Tested and it has been demonstrated that the new system is calculating pays and other payroll outputs within acceptable accuracy parameters, the Parallel Test can be completed.
The next step is to present the result of the Parallel Test to stakeholders/steering committee and request permission for go live to proceed.
Once the stakeholders have approved the go live, the project can move into the “go live” and “post go live support” phases.
Tips:
The steering committee meeting should focus on briefly summarising the Parallel Test results. Then any defects yet to be resolved and/or any risks attendant to going live should be discussed in detail. Mitigations for risks should be presented. The project team should also provide a recommendation about whether to proceed with the go live or not.
Conclusion:
Parallel Testing is notoriously complex and time consuming. However, each step of Parallel Testing provides opportunities to enhance the project’s overall effectiveness. In the first part of this 2 part series, tips were given on how to plan Parallel Testing thoroughly and thoughtfully. In this, Part 2, advice has been given on how to identify and exploit opportunities to enhance overall project effectiveness in each phase of Parallel Testing. Careful planning and using the opportunities presented throughout Parallel Testing will ensure that the Parallel Test not only runs efficiently – but that it makes a significant contribution to the overall quality of your HRIS/payroll implementation.
About the author:
Bernadette Chandrasegaram is an independent consultant who works with clients seeking to optimise their support functions. For more information, please go to www.bc-online.com.au
Copyright 2010 Bernadette Chandrasegaram, all rights reserved.