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.

Testing Basics and Beyond

Testing is the operation or use of a product for the purpose of gathering information about it. If we are the product developers, we execute tests to find what kinds of errors still exist -- this is conventional wisdom testing. If we are Year 2000 (Y2K) evaluators, we execute tests to do the following:

  1. Locate Y2K sensitivities in the product -- places where we may have to make changes
  2. Ensure that the renovated (changed) product operates as well as it did prior to renovation -- regression testing
  3. Determine how well the renovated product will operate at the Y2K transition and afterwards -- validation testing

As testing proceeds, and when completed, we use the information gathered to establish the risks that the product will not support its users' needs before, during, or after the Y2K transition. We use this information, our knowledge of the users' way of working, and the users' inputs to determine whether or not these risks are acceptable. Finally, if the risks are not acceptable, we use the information that we gathered to develop mitigation strategies. The first two of these, establishing and analyzing risks, is called evaluation. The third, mitigating, may lead to renovation or it may lead to changes in operating procedures, or to product retirement. When the renovation is complete, if the mitigation process leads to renovation, we evaluate again.

Locate Date Sensitivities
For many applications, particularly newer ones, date sensitivities can be determined from available documentation and source code. Requirements specifications and design documents (if they are current and contain adequate detail) are particularly useful sources of information. Additionally, user documentation (maintenance guides, if they exist, and user manuals) can also identify date-related functions. The source code, of course, is the ultimate identifier of date functions within an application.

Most of this documentation, including the code, doesn't say much about how the surrounding "infrastructure" uses dates. By infrastructure, we mean:

To establish date sensitivities of these infrastructure components, each must be evaluated individually, or the complete system, application plus infrastructure, must be subjected to a series of tests that explore operational behavior around those dates that are critical to the system's mission.

Ensure Renovations Haven't Broken Anything
Once Y2K modifications have been made, the tester/evaluator must determine if anything was broken by the fixes. This is called regression testing. In the strictest sense of the term, the only true regression test is a complete retest of the product against all relevant specifications (including user expectations and current modes of operation). Often, though, it is possible to develop some subset of such a complete test that can be used as a health check to determine if any critical functionality has been lost.

 

Verify Y2K Operation
Validation of correct Y2K operation (in all its forms) involves operating the product in a "time-advanced" environment. A number of tests are required, at least one at each of the identified critical dates and one for each relevant date horizon at each critical date.

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