What is Parallel Testing and How do you Plan for it?

So you’re entering the implementation phase of your new HRIS/payroll software product.  How do you determine if your new HRIS/payroll system is performing as you expect it should?  It’s called Parallel Testing. The below article was originally posted on compareHRIS.com.

Parallel Testing is the most complex part of HRIS/payroll implementation

The complexity of Parallel Testing is due to several factors, some of these being:

• The high level of coordination needed to ensure that all data inputs are available
• The labor intensiveness of entering payroll input data into the new system
• The fact the test involves the use of highly sensitive production data that deals with remuneration across the whole organization.

Parallel Testing is also arguably the most important part of a HRIS/payroll implementation because it provides assurances that employees’ pay is being calculated correctly.

What is Parallel Testing?

In a HRIS implementation, the essential objective of Parallel Testing is to prove that payroll is being calculated accurately. To make this assertion, a Parallel Test follows these basic steps:

1. Reserve all inputs and outputs produced by the legacy system during selected pay cycles
2. Enter the reserved inputs into the new HRIS once parallel testing starts
3. Run payroll in the new system over the inputted data
4. Compare the outputs from the legacy system (reserved in step #1) to the outputs from the new system

Any discrepancies between the two outputs need to be explainable – and acceptable.

Even if payroll functionality is not being implemented as part of the HRIS project, some element of parallel testing is necessary to ensure that data is being passed from the new HRIS and processed by the legacy payroll accurately.

The Parallel Test phase is one of the last phases of a HRIS implementation. It must not be the first time the business rules and payroll calculator are tested so it occurs after the functional/system test phase. Furthermore, Parallel Tests are dependent upon the successful completion of Conversion Script Testing. Conversion scripts are required to “populate” the new system with the foundational data required to ready the new system for Parallel Test data input.

Planning the Parallel Test Phase: 8 Considerations

1. What pay cycles will be tested in the Parallel Test phase?
Pay cycles selected for Parallel Testing should not have an unusually high amount of input data. Examples of cycles with high volumes of input data are: annual salary review cycles and cycles coinciding with a large employee intake, such as graduate onboarding. Too much data entry risks overwhelming Parallel Test resources and thus potentially compromising time lines.

Conversely, it is important not to pick a cycle with abnormally low transaction volumes. For example, pay cycles that coincide with major national holidays such as Christmas, or Eid. Selecting such cycles will limit your ability to “test” a realistic variety and volume of transactions.

2. How many pay cycles should be Parallel Tested?
Any Parallel Test must consist of at least two pay cycles. The first Parallel Test cycle is generally marred by a lot of data input and technical errors. Essentially this cycle can be considered a “shake down”.

Two pay cycles generally provide enough information to determine whether the new system is accurately calculating pays. However, it is worth keeping inputs and outputs of a third legacy pay cycle in reserve as a contingency.

3. Will your pay cycles be consecutive?
Selecting consecutive pay cycles is advisable. Testing consecutive pay cycles provides several benefits:

• The new system will only have to be “set up” with converted data from the legacy system once
• A more “real life” like scenario is presented
• It will be possible to observe how the data is handled across two successive pay cycles

If there is a compelling business reason not to test consecutive pay cycles, it is advisable to develop a risk mitigation plan. The plan will confirm how specific tests, such as the automatic incrementing of the output file number, will be tested and; whether accruals are occurring correctly across pay cycles.

4. What will be tested?
In addition to checking the calculation of pays, Parallel Testing should also check:

• The calculation of leave liabilities
• Output files such as: retirement fund contribution files, taxation files, files to benefits providers, and files used to update the General Ledger (GL).

It is also important to consider whether it is necessary to test output files from the new system being successfully uploaded by recipients. Such tests require a lot of lead-time and liaison with the receiving parties. Therefore, it is advisable to begin planning discussions for these tests as soon in the project as possible.

Note: if payroll is not being replaced as part of the HRIS implementation, these tests will be less important as the file format will not change.

5. What verification methods will be used?
Agreement of the methodology to compare new and legacy system outputs and to identify discrepancies is required before beginning Parallel Testing. A thorough Parallel Test will involve a line-by-line comparison of every row of at least the payroll output files.

Most vendors will have tools that facilitate comparing the two output files and highlighting any differences between the two. If no tools are available, a good work around is to export both files to Excel and use V-lookup to identify differences. Once the verification methodology has been agreed upon, it is necessary to determine how to categorize each discrepancy found between the new and legacy system outputs.

6. How will discrepancies be categorized?
Below are some examples of the types of discrepancies found in Parallel Tests and how they can be categorized:

• Data entry/ Business Process errors: These discrepancies are defects, but not with the new HRIS. They can be addressed by “tweaks” to the business processes; user training and/ or user guides.
• Explainable and acceptable differences: These discrepancies are caused by the new HRIS but are not defects. For example, slight discrepancies may be caused by differences in the respective systems’ method of rounding up or down. These discrepancies require no action.
• Legacy system errors: Sometimes Parallel Testing reveals existing errors in the legacy system, corrected by the new system. Stakeholders may wish to do nothing about these discrepancies, or they may wish to develop some communications to the employee population regarding this situation: – it will depend on the scale of the legacy system error.
• Business Rule configuration errors: Many discrepancies will be due to the fact that there have been slight errors in the configuration of business rules. For example, rules governing leave accruals. These discrepancies are defects and will need to be corrected and the payroll re-run to ensure that these errors have been rectified.
• Unexplainable errors: These discrepancies are defects of the highest severity in a Parallel Test. Even a discrepancy of 1¢ must be explainable. Otherwise, it represents an unacceptable risk to the business as there is no way to know why the engine is calculating 1¢ more/1¢ less. Moreover, there can be no assurance that in subsequent runs the difference will not be of a greater magnitude.

7. Who will participate in the Parallel Testing?
Many HRIS projects focus mainly on finding the above discrepancies and hence put little thought into how the data will get into the system in order to run the payroll engine and produce the output files. The second part of Parallel Testing, entering payroll input data, provides the opportunity to:

• Test the new processes designed to use the new system
• Test the degree to which the people who will be using the system have understood the new data entry requirements.

To capitalize on this opportunity, every effort should be made to facilitate the operators who will be responsible for the data entry once the system goes live, those being the people completing the requisite data entry for the Parallel Phase.

The challenge posed by this approach is that these operators will essentially double their workload during the data entry part of the Parallel Test; not only will they be entering data into the new system for Parallel Testing, they will also be required to continue to enter data into the legacy system for the current, live payroll. Thoughtful planning is needed to:

• Ensure the pay cycles selected for Parallel Testing are not too large (refer to #1 in this article).
• Take measures to streamline the live workload to make the increased workload for operators manageable.

8. How will you communicate progress with the steering committee/stakeholders?
Finally, it is important to determine and plan communication meetings to the steering committee/stakeholders who ultimately need to approve the go/no-go decision for the system implementation. Recommended communication meetings are:

1. Kick off meeting: held at the start of the Parallel Test Phase to explain: tasks, timelines, and how progress and test results will be reported to stake holders
2. Status meetings: should occur at the planned end date of each parallel cycle. These meetings will focus on: planned vs. actual progress, a summary of all discrepancies found, and a detailed analysis of any high severity defects.
3. Go/no-go meeting: held at the end of the last parallel cycle. Presents a final summary of all discrepancies and recommended work-arounds for any low severity defects that remain open. The project team will recommend whether to go live, or not. However, ultimately it is the stakeholders’ decision whether it is acceptable that the implementation proceeds. It is advisable to book stakeholder meetings well in advance as the calendars of required attendees to these meetings generally fill up quickly.

This article is part one in a two part series. Part two of this article will walk you through the various “sub-phases” of Parallel Testing and give some advice for maximizing the effective execution of these sub-phases. You may read part two here, Executing Parallel Testing in HRIS/Payroll Software.

About the author:
Bernadette Chandrasegaram is an independent consultant who works with clients seeking to optimize their support functions.
Copyright 2010 Bernadette Chandrasegaram, all rights reserved.