|
This report from MIDRANGE SYSTEMS (Jan. 19) is to the point: the fourth and crucial test of any y2k repair involves shared data. The internally fixed system must be tested with all interconnecting systems.
Now, consider Union Pacific Railroad. It has 16,000 suppliers, each with its own software. Union Pacific is typical of most large manufacturing organizations.
The happy-face press releases from all the noncompliant companies -- which means all companies -- ignore this issue.
* * * * * * *
Shock assessment. Probably the most basic test you can perform to test the impact on your system is to simply set the clock forward, says Allan Graham, VP of Comdisco's Continuity Services (Rosemont, Ill.). "You might not get very far in that kind of a test, but at least you'll immediately understand if you have a problem, and if that problem affects you in a critical area." Graham recommends securing an outside system to do this assessment.
Unit testing. Individual programs need to be run as actual code conversion progresses, Graham says. This can be done within the company's development environment.
Checkpoint testing. This is where third-party packages need to be run, Graham says. "You need to test your packages as a system. You want to ensure that everything is working in concert." A company's approach to a fix may differ from an application vendor's fix, and the two may not mesh. "You may be expanding your date fields, but your software vendor might be using a windowing technique," Graham says. "Since you don't typically have control of the source code, you need to do some testing to ensure things work together on a broader basis."
Validation tests. "If you believe you've corrected everything, now it's time to test it all as a system," Graham says. A key part of this process is "data exchange testing to other systems, outside vendors, business partners and customers. That's the true validation of your system, that you are in fact are going to get through it."
|