Y2K Site Map | Terms of Use | Problem | Steps | Certification | Briefings | Compliance | Solutions | BIOS | Test & Evaluation | Cost


The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.

How Y2K Strategies Affect the Testing Approach

There are a number of ways that software developers will attempt to achieve Y2K compliance in their products. The Y2K solutions that an evaluator is most likely to encounter are:

System Replacement
We can dispense with replacement quickly because the new system must be evaluated just like any other new development, except that Y2K survivability is a requirement.

Field Expansion
Field expansion is the "right way" to achieve Y2K compliance because it converts the product to dates with full four-digit years, but it is also the most far-reaching because it is applied to the data files with which the product works. This requires changes to data, data structures, and to code. Components of the product that reference the altered files, even if they perform no date manipulations, must be recompiled to accommodate the new date structures. It is by far the most comprehensive, but it also requires the most testing -- virtually everything is put at risk.

Field Compression
Field compression also involves changes to data; specifically it requires encoding or "packing" the four-digit year into the two digits currently allocated. Data must be changed, as must code. Whether or not data structures must change depends upon the compression algorithm and the language involved. Each date reference is a possible candidate for change and, hence, for testing.

Field Windowing
Field windowing doesn't require changes to data, but does require significant changes to the code. In complex products, with many date manipulations that cannot be isolated in a few places, the risk of inadvertently changing something not intended can be quite high. If this is the case, field windowing may require a great deal of regression testing. If, on the other hand, the date manipulations are localized, field windowing may require the least regression testing of any technique.

Program Encapsulation
Program encapsulation requires little or no change to the existing source and aging of master files. Because systems do not encounter the year 2000, it makes future date testing optional.

Test & Eval Testing Basics Renovation Strategies Product Evaluation Critical Dates
Resource Allocation Interface Management Interface Agreements Interface Status Confidence Assessment

For further information directly related to Year 2000 issues, please contact Year2000@mitre.org
 
Information is provided by the MITRE Y2K Team
Last modified: Thursday, 14-Feb-2008 09:21:03 EST