Year 2000 Test Methods

Christina Drukala <christinad@abtcorp.com> reports on the July 1997 meeting in Nashua NH.

ABT Corporation, a project management software developer, was faced with creating an internal Test Methods document to test readiness for their applications for the millenium change. While researching samples of cases, functions, and features at risk, we found a void of information. However, there was a plethora of Strategic data defining the problem and describing the disaster we were all going to experience if we did not correct this problem in a timely fashion. The available information discussed the maturity of processes necessary to implement a correction program, including the disciplines to be involved and the cost of remediation. This is valuable data but did not enumerate the tasks a Test Engineering department should perform to validate an application system, etc. So we started to develop our own test methods.

This internal ABT Corporation document was reviewed by the IEEE Year 2000 Study Group formed at the Jackson Hole, Wyoming PASC meeting in April 1997. At that meeting, the group adopted the ABT guidelines as the starting point for creating a Year 2000 Test Methods Recommended Practice. The core document is being developed by a group of Test Engineering and Quality Assurance professionals, together with members ranging from government employees to lawyers.

The recommended practice is not intended to be a certification standard. Its intent is to serve as an outline for personnel responsible for the testing of applications that have a finite size for storing date information in the event that the size is not sufficiently large. The most obvious case of this is holding a year in a two-digit format, and handling the case of 99 rolling over to 00, but the practice will be equally applicable to other counters (e.g., the 32 bit POSIX time_t value in 2038). The document helps identify those modules known to have problems; and this list can be compared against the functions and procedures used by the system, application, and firmware. A single module in the application may have similarities to several of the general modules listed in the document. In addition, the document provides sample test scenarios that include purpose, environment, steps for replicating, and expected results that map to the modules/ functions in the risk section of the Recommended Practice document. A small section includes test methodology along with definitions of remediation techniques.

For the last two meetings, in April and July, the group has been meeting as a study group, but is now ready to submit the Project Authorization Request (PAR), and expects sponsorship to be recommended in the October PASC meeting in Reno, Nevada. Before that, in late August, a core group will meet in Reston, Virginia for a two-day formal review of the Recommended Practice draft. Ideally, this document will go to IEEE ballot in early Spring 1998, in time for a summer general availability. Obviously, with the subject in question, timeliness is key, and this will be an interesting challenge to the usual tardiness observed in the ballot process.