Planning the right tests for year 2000 compliance

HR Magazine, Nov, 1998 by Nathan Schuck

Given the dependence of human resource systems on effective date sequence, it is no surprise that many HR managers - and chief financial officers-view the approaching turn of the century with trepidation. While requirements for feasible solutions vary by organization, the basic, general testing strategies outlined here can be used to generate a plan for testing system functions. In addition, I highly recommend contacting a reputable testing consultant for advice on your specific system requirements.

A successful testing project should begin by defining the scope of tests, and what they will measure, in order to determine what kind of test scripts will be created. The scope of Year 2000 testing can be broken into three critical priorities: areas that directly determine whether the organization can continue to do business, whether business can be conducted using the existing procedures and whether end users can conduct business easily and efficiently.

Ideally, testing should be done for all three priorities. Given time constraints, however, organizations may need to limit testing to those issues that could lead to an interruption in business. In defining what is critical, first determine which units of the system are at risk. For HR, the areas of risk are commonly benefits eligibility, probationary periods, payroll and leaves of absence and future-dated transactions.

The specific critical needs for a testing plan will vary depending on the business processes in place in each department. For the HR manager, the first action item is to assess whether or not the department could function if a given system module should fail. Other departments involved should make the same evaluation independently.

THE FIVE PHASES OF SYSTEM TESTING

Critical testing has five separate phases: baseline testing, unit testing, system testing, user acceptance testing and parallel testing. This separation permits the isolation of errors and helps prevent a "domino" effect that makes tracking the source of the error much more difficult and time-consuming. For example, a domino effect could begin with an error made in one system unit at the beginning of a process. That error carries over to a second unit, causing miscalculation of other essential data, then more errors can occur in other units throughout the process. Though the error existed only in the first unit, the second unit may also be suspect in trying to track down the error, which would result in lost testing time. Ideally, testing is accomplished using multiple environments - development, testing and pre-production - that mirror the actual production environment. This helps isolate areas from system testing until they have passed the unit tests.

1. Baseline testing. This process is used only for identifying, locating and documenting potential errors in the current system before modifications are made, which sets a control point for calculating the measures of completion. The baseline test is used primarily in a "fix the system" scenario to determine the scope of modifications needed. When used in a "replace" scenario, the test is generally used to justify purchase of a new system and set the minimum performance criteria for system selection.

In practice, baseline testing requires that scripts be prepared and run against the existing system (more on scripts later). The scripts can be automated or performed manually on the system; the primary objective is to keep the testing static and uniform.

The baseline testing phase can be further divided into current date tests and future date tests. During this phase, assume that all tests involving current dates will be successful and that scripts will be used later with the new or modified system. Future date tests are used to establish required performance criteria. While they may fail in the current system, they are expected to pass in the new or modified system. Again, no fixes should be applied or attempted during baseline testing; the problems are documented and will be resolved later according to the organization's policy.

2. Unit testing. This phase is for tests of individual modified modules or programs to ensure compliance and functionality based on the goals established during baseline testing. As modules pass this phase, they are ready for system testing.

3. System testing. This phase begins when all the programs within a system are changed and have successfully passed unit testing. All programs or modules are tested in conjunction with other supporting or related modules, and the results are measured against the goals established during baseline testing.

System testing uses the same data, test scripts and other criteria used during baseline testing to make sure no errors were introduced during the upgrade or fix that would compromise existing functions. Results should be identical to those obtained during current date testing. For future date testing, the results should be compared against the desired results, as documented during baseline testing.