Software Parallel Testing – Do I really Need to Do It (and if so, how)?
Posted: Tuesday, January 18, 2011
by Teresa Francis
Accounting Software Success
Parallel Testing can be one of most complex parts of an Accounting Software System implementation. The complexity 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 data into both the new system and the old; the fact data may be incongruent due to changes in the coding structure in the new system. Parallel Testing is arguably an important part of an implementation because it provides assurances that financial data is being coded and reported correctly. On the other hand, if you are moving from a manual system, or your changes in coding / reporting are so great that comparisons are meaningless, you may want to only test processes as opposed to truly running parallel.
In an Accounting System, the essential objective of Parallel Testing is to prove that data 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 a selected cycle (week/month)
2. enter the reserved inputs into the new accounting system once Parallel Testing starts
3. run reports in the new system over the inputted data
4. finally, compare the outputs from the legacy system (reserved in step #1) to the outputs from the new system.
The comparison facilitates testing the new system by comparing its output to the output of the legacy system. Any discrepancies between the two outputs need to be explainable - and acceptable. Frequently parallel testing will also be used to assure that data converted from the old system to the new is accurate. The Parallel Test is typically one of the last phases of an implementation. It must not be the first time the business rules and calculations are tested so it generally occurs after the functional/system test phase.
Planning the Parallel Test Phase: Considerations
The following six questions will prompt the necessary considerations to thoroughly and fully plan a Parallel Test effort.
- What cycles will be tested in the Parallel Test phase? Will you test a day? A week? A month?
- What segments will be tested? Will we test the entire organization? Just an AP run? A payroll run? A single department?
- How many Parallel Tests will we run? Any Parallel Test will generally be done twice. The first Parallel Test cycle is often marred by a lot of data input and technical errors. Essentially this cycle can be considered a “shake down”. The second would expected to “fix” these issues and insure the new system is accurately calculating and reporting activity.
- 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 account and transaction of at least the financial reports, especially if discrepancies exist. Most vendors will have tools that facilitate comparing the two output files and highlighting any differences between the two. This could include exporting both reports to Excel and use V-lookup to identify differences. Once the verification methodology has been agreed, it is necessary to determine how to categorize each discrepancy found between the new and legacy system outputs.
- How will discrepancies be categorized?
It is important to determine how discrepancies found between the legacy system and new system outputs will 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 system but are not defects. For example, slight discrepancies may be caused by differences in the respective systems’ method of rounding up or down. In addition, changes in coding may affect reported balances. 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. These discrepancies are defects and will need to be corrected and the reports 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 cent must be explainable. Otherwise, it represents an unacceptable risk to the business as there is no way for knowing why the engine is calculating 1 cent more/ 1 cent less. Moreover, there can be no assurance that in subsequent runs the difference will not be of a greater magnitude.
- 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:
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
Status meetings: should occur at the planned end of the parallel run. These meetings will focus on: planned vs. actual progress; a summary of all discrepancies found and; a detailed analysis of any high severity defects.
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.
About the Author
John S. Francis graduated with his MBA from Southern Illinois University- Carbondale in 1985. Since that time he has worked in various accounting professions. From 1996 to 2009, he was founder and President of one of the country’s leading accounting software implementation firms. Acknowledged as a “Top 100 Technology Pacesetter” and a “Killer VAR” by Accounting Today magazine, and a “Top 100 Value Added Reseller” by Accounting Technology magazine, his firm successfully managed accounting system implementation and training engagements for thousands of clients worldwide. In 2009 he began working on accountingsoftwaresuccess.com , a site dedicated to assisting accounting professionals with their search, selection, implementation and use of accounting systems. The site contains several tools to assist accounting professionals with their accounting software research including an Accounting Software Selection Tool and an Accounting Software Articles Library .
This Article has been viewed 320 times. (Not updated in real-time.)
No comments yet.We want your comments! If you can read this, you don't have javascript enabled, so you can't use this comment system. Please enable javascript.