Test and Validate Each Application
In testing an application that has been modified to be Y2K compliant, normal testing procedures to catch errors are still applicable. Departments that don't have well-defined, comprehensive testing procedures might want to look at the University standards for testing, in sections 2.11 and 2.12 of the UC Business and Finance Bulletin IS-10, October 1997.
Normal testing procedures should be augmented in two ways. First, with the system clock set to current date, use a wide range of test transactions with future dates (room reservation dates or expected graduation dates or whatever is applicable), for all cases where the application has transactions that use future (forecasting/reservation) dates.
Second, the system should be tested as if it were operating on dates in the future - what is called "time machine" testing. If at all possible, use a separate (non-production) computer. Make a full image or full backup of this computer's hard drive(s), then set the clock forward to critical dates. Those dates should include 1/1/2000; 1/31/2000 (or whenever the first month-end processes are run, if any); 2/29/2000; 3/31/2000 (or whenever the first quarterly processes are run, if any); and 6/30/2000 (or whenever the fiscal year-end processes are run, if any).
The goal is to test a representative set of transactions for each critical date, moving forward in time.
Be aware that moving the clock forward may cause some licensed applications to stop working because their license period has expired (that's why a full backup is highly desirable; the system can be restored as is). If there is a possibility of licenses expiring, and the licensed applications are needed to test the customized application being modified, it is best to contact the vendor for possible workarounds, preferably before starting the testing.
At least one vendor, Omnesys, has a product that my reduce or eliminate
clock date problems. Omnesys says that its product, Omnesys VC2000,
provides applications with their own view of the system clock. Multiple
applications on the same machine may each have their own notion of the
current time, simultaneously. The product is available for Solaris 2.6,
Solaris 2.5.1, Solaris 2.4, SunOS 4.1.3_U1, Windows NT 4.0 Workstation and
Windows NT 4.0 Server, AIX 4.2.1, and AIX 4.1.4.
At least one vendor, Omnesys, has a product that my reduce or eliminate
clock date problems. Omnesys says that its product, Omnesys VC2000,
provides applications with their own view of the system clock. Multiple
applications on the same machine may each have their own notion of the
current time, simultaneously. The product is available for Solaris 2.6,
Solaris 2.5.1, Solaris 2.4, SunOS 4.1.3_U1, Windows NT 4.0 Workstation and
Windows NT 4.0 Server, AIX 4.2.1, and AIX 4.1.4.
If possible, for each date tested, the dates on records and transactions in the database should also be aged (before running new test transactions through). Realism is an important aspect of testing; part of realism is to have database information be representative of what really would be in the database as of that clock date.
When you're done testing, restore the computer to the way it was. Doing a restore eliminates possible problems with database logs or other situations where out-of-sequence transactions (time-wise) could cause problems.
Finally, interface testing, which should be part of normal testing, may be more complicated if you want to simulate sending transactions dated (say) January 3, 2000, to another application. This "end-to-end" testing approach is the best way to have the two applications interface properly when the year 2000 arrives, but it requires cooperative efforts by whoever owns the application being interfaced to.
Return to Seven Phases to Y2K Compliance
|