"There has never been a time when so much code was being examined, changed and tested at the same time. Not only will most of the software in each agency be changing, but simultaneously, most of the code in every other interfacing agency will also be changing. The rigorous testing environments required to implement such a complex scenario will require careful planning."
The Honorable George Muņoz
Assistant Secretary of the Treasury for Management
Although it is widely estimated that testing will account for 45 - 55% of cost to correct the YR 2000 problem, surprisingly there is little information about the unique Year 2000 testing concerns. A good general discussion of testing for Year 2000 compliance is contained in IBM's The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation. Additionally, year 2000 compliance criteria and a validation strategy are contained in the Validation Phase of the Air Force Year 2000 Guidance Package. Finally, an abstract of TECH-Beamers white paper Year 2000: Focus on Testing provides more general Year 2000 validation information.
The year 2000 problem is pervasive and has a well known deadline and creates special considerations for validation of renovated systems. This particularly applies to aged legacy systems. In such cases, test cases may not exist, the source code that produces the undesirable year 2000 results may well be unavailable, unreadable, impossible to recompile, undocumented or legally inaccessible because of contractual "ownership" issues. In other cases, year 2000 compliant systems are negatively affected by input data from other non-compliant systems. In fact, studies reveal the majority of year 2000 problems will manifest themselves at the interface level. Often this problem is aggravated by less obviously involved embedded software in systems and subsystems. The rapid growth of electronic communications systems also tend to propagate and worsen this potentially serious phenomena.
Identifying the manipulation of date information to be tested can often be difficult. Date manipulations may span hundreds of lines of code within a given application. In some instances, these manipulations can occur across related programs or within or among supporting utilities. Often, year manipulations are embedded in controllers, firmware based micro-code, operating syst>