Milgo Solutions: Year 2000 Compliance Product Test Requirements

Year 2000 Compliance Product Test Requirements

1.0 Hardware/Firmware/Embedded Software Test Requirements

Each test in this section must be executed and demonstrated to pass for a hardware-based platform to be certified as Year 2000 compliant. All passing results should be noted with a "Pass" in the Section 1.0 matrix of the Test Report. All non-compliant results must be flagged as "FAILED" in the report matrix, with additional details reported under "Comments" as needed. If the product is a standalone software application, enter "N/A" in the "Comments" field for this section and continue testing with Section 2.0.

1.1 Key Date Rollover Tests

The following dates should be entered and the unit run across midnight to the following day. To pass this test the system must rollover successfully to the correct date and do so without any interruption to data flow or operation.

1.1.1	December 31, 1998 to January 1, 1999 Testing for date performance one year in advance can be used to ensure product calendar is set up properly. Testing here first, indicates that the product will have "consistent behavior prior to YR2000"
1.1.2	December 31, 1999 to January 1, 2000 This is the actual change from 1999 to year 2000.
1.1.3	December 31, 2000 to January 1, 2001 The 21^st Century will begin January 1, 2001. The 20^th Century consists of the years 1901 through 2000 and will end December 31, 2000.
1.1.4	February 28, 2000 to February 29, 2000 Year 2000 is a Leap Year.
1.1.5	February 29, 2000 to March 1, 2000 Year 2000 is a Leap Year.
1.1.6	September 9,1999 to September 10, 1999 The date 9/9/99 was used sometimes in programming as an expiration for archived data or situations that were intended to have "No Expiration Date"

1.2 Date Entry Tests

Verify that the product can be set to the dates below. To pass this test the system and its components must be successfully set to each of the above dates by each method of date entry (e.g., front panel, console port, NMS).

1.2.1	January 1, 1999
1.2.2	February 28, 1999
1.2.3	March 1, 1999
1.2.4	December 31, 1999
1.2.5	January 1, 2000
1.2.6	February 28, 2000
1.2.7	February 29, 2000
1.2.8	March 1, 2000
1.2.9	January 1, 2001
1.2.10	February 28, 2004
1.2.11	February 29, 2004
1.2.12	March 1, 2004

1.3 System Reboot Tests

Verify that the product can be rebooted on the following dates and that the system will then come up on the set date (e.g., the product will properly boot and the date will not be reset to an incorrect value).

1.3.1	January 1, 1999
1.3.2	February 28, 1999
1.3.3	March 1, 1999
1.3.4	December 31, 1999
1.3.5	January 1, 2000
1.3.6	February 28, 2000
1.3.7	February 29, 2000
1.3.8	March 1, 2000
1.3.9	January 1, 2001
1.3.10	February 28, 2004
1.3.11	February 29, 2004
1.3.12	March 1, 2004

1.4 Unambiguous Century Test

To pass this test it must be demonstrated that the century for all dates stored or processed by the system or any of its components is unambiguous. If explicit 4-digit date representation is utilized, this requirement is satisfied by design. If implicit 2-digit date representation is utilized, the inference rules used for semantic interpretation of date information (i.e., for date XX, if XX < 25, date is 20XX, otherwise date is 19XX) must be consistent throughout the product. All date input, display, and storage means should be examined. Verification of consistency should be made under "Comments" in section of the Test Report. Any inconsistencies should be noted, and, as is practical, screen snapshots or other documentation of problems should be filed with the Test Report.

2.0 Network Management/Software Application Test Requirements

All hardware products with network management shall have the product-specific management software (including key management for cryptography products) tested and reported on the same Test Report as the hardware product itself. In addition, all standalone software applications (e.g., TrustMe) must be tested under the requirements of this section. All passing results should be noted with a "Pass" in the Section 2.0 matrix of the Test Report. All non-compliant results must be flagged as "FAILED" in the report matrix, with additional details reported under "Comments" as needed. If the product is not a standalone software application, and does not have network management software, enter "N/A" in the "Comments" field for this section and continue testing with Section 3.0. For products with multiple NMS variants, attach additional test result matrices for Section 2.0 of the Test Report, as required.

2.1 Key Date Rollover Tests

2.1.1	December 31, 1998 to January 1, 1999 Testing for date performance one year in advance can be used to ensure NMS application's calendar is set up properly. Testing here first, indicates that the product will have "consistent behavior prior to YR2000"
2.1.2	December 31, 1999 to January 1, 2000 This is the actual change from 1999 to year 2000.
2.1.3	December 31, 2000 to January 1, 2001 The 21^st Century will begin January 1, 2001. The 20^th Century consists of the years 1901 through 2000 and will end December 31, 2000.
2.1.4	February 28, 2000 to February 29, 2000 Year 2000 is a Leap Year.
2.1.5	February 29, 2000 to March 1, 2000 Year 2000 is a Leap Year.
2.1.6	September 9,1999 to September 10, 1999 The date 9/9/99 was used sometimes in programming as an expiration for archived data or situations that were intended to have "No Expiration Date".

2.2 Date Entry Tests

Verify that the application(s) can be set to the dates below. To pass this test the system and its components must be successfully set to each of the below dates by each method of date entry.

2.2.1	January 1, 1999
2.2.2	February 28, 1999
2.2.3	March 1, 1999
2.2.4	December 31, 1999
2.2.5	January 1, 2000
2.2.6	February 28, 2000
2.2.7	February 29, 2000
2.2.8	March 1, 2000
2.2.9	January 1, 2001
2.2.10	February 28, 2004
2.2.11	February 29, 2004
2.2.12	March 1, 2004

3.3 System Reboot Tests

Verify that the application(s) can be rebooted on the following dates and that the system will then come up on the set date (e.g., the product will properly boot and the date will not be reset to an incorrect value).

2.3.1	January 1, 1999
2.3.2	February 28, 1999
2.3.3	March 1, 1999
2.3.4	December 31, 1999
2.3.5	January 1, 2000
2.3.6	February 28, 2000
2.3.7	February 29, 2000
2.3.8	March 1, 2000
2.3.9	January 1, 2001
2.3.10	February 28, 2004
2.3.11	February 29, 2004
2.3.12	March 1, 2004

3.4 Day-of-Week Tests

The days of the week of the following dates shall be checked. This requirement need only be tested if the application uses or display weekdays. If it does not, enter "N/A" in the Test Report and proceed to the next section. To pass this test the system or system component (e.g., NMS and Java applet) must successfully display the correct day of the week for each of the below.

2.4.1	January 1, 1999 will be a Friday
2.4.2	February 28, 1999 will be a Sunday
2.4.3	March 1, 1999 will be a Monday
2.4.4	December 31, 1999 will be a Friday
2.4.5	January 1, 2000 will be a Saturday
2.4.6	February 28, 2000 will be a Monday
2.4.7	February 29, 2000 will be a Tuesday
2.4.8	March 1, 2000 will be a Wednesday
2.4.9	January 1, 2001 will be a Monday
2.4.10	February 28, 2004 will be a Saturday
2.4.11	February 29, 2004 will be a Sunday
2.4.12	March 1, 2004 will be a Monday

2.5 Unambiguous Century Test

3.0 Clock/Calendar Implementation and Functionality

While not a requirement for Year 2000 compliance per se, documentation of the clock and calendar implementation and functionality may be of benefit in certain Year 2000-related requests from customers and other interested parties. To that end, where practical and feasible, each Test Report (for both hardware products and software applications) shall contain a brief summary of clock/calendar usage and algorithms as they are known and understood. This final requirement is not intended to be technically exhaustive, but merely to summarize the most evident aspects of the clock and calendar operation. For some products, especially those that are dated, sufficient expertise to complete this requirement may not be readily available. Note that it is extremely important that each test result indicate the range of dates for which the calendar is known to operate correctly. If at all possible, this information should be derived directly from the calendar algorithm. Where this approach is not feasible, the tester should pick a date (January 1, 2028 or later is recommended) and perform the tests in Section 1.0 and Section 2.0 to verify operation. Once operation is found to be correct in a year at least 15-20 years hence, that year shall be selected as the latest year in which operation is warranted to be correct. Any additional test results required should be included in the final test package.

4.0 Signatures and Approvals

Upon completion of all tests, the last section of the Test Report must be formally completed to document the test completion date and approval. The lead test engineer should sign and date the form and obtain approval of the Director of Engineering responsible for the tested product. The latter approval is included to ensure testing consistency and completeness. After all signatures are obtained, the original report shall be collected by the appropriate Program Office for tabulation in the corporate Year 2000 product test matrix and subsequent dissemination to the Sales Regions. After completion, the Program Offices shall file all original Test Results with the Legal Department for permanent archival. Engineering and the Program Office should each retain copies for their records.