The Need for Year 2000 Testing
Your testing phase of Y2K should be well under way. Discover a sure-fire technique, date simulation, to verify your work.
Today, the Year 2000 problem has been recognized as a real threat tobusiness and governments around the world. Accordingly, almost all businesses have a Y2Kcompliance program in place, and many have made significant progress in remediating theirsystems. The solution is highly cost-intensive, requiring legions of knowledgeableprogrammers who can search through and fix the millions of lines of computer code within atypical large organization. The Gartner Group (Stamford, Conn.) estimates that it couldcost $600 billion to fix the problem worldwide. Many organizations are now finding thattheir Y2K compliance requirements are bigger and more costly than anticipated.
The basic steps required to make a software program or system Y2K-compliant include:
- Awareness
- Evaluation Testing and Risk Assessment
- Renovation, Modification or Correction
- Verification Testing and Validation
- User Acceptance and Implementation
It has been estimated that Y2K software testing will require about 50 percent of thetotal conversion time and effort. Applications must be tested not only to make sure themodifications will work as intended after January 1, 2000, but also to make sure no newbugs were introduced during the conversion process. Implementing a comprehensive andworkable test plan is essential to ensure that the applications will work correctly wheninstalled in production.
With regard to your Y2K compliance project, there is both good news and bad. The badnews is that the deadline is firm and your testing costs will be significant. However, thegood news is that there are proven methods for reducing the cost and time of testing.
Overview of Testing
Testing is done at two stages in the Y2K compliance process. During the evaluation andvalidation testing phases, the software or system is subjected to a series of test casesdesigned to validate the correct use and processing of date information. First, evaluationtesting is done to locate Y2K sensitivities where changes in the software will need to bemade. After the changes/modifications are made, regression and validation testing isperformed to ensure that the renovated software operates, as well as it did prior tochanges and that it will operate at the Y2K transition and afterwards. Testingmodifications are among the most critical and expensive aspects of a successful Y2Kprogram.
The conventional definition for testing is the execution of a software program orsystem for the purpose of detecting errors and gathering information about it. Within theY2K context, we need to modify that definition and add a definition for evaluation. ForY2K purposes, testing is done to detect errors and to determine the risk associated withwhether the software or system under consideration will or will not adequately support thedesired user capability or mission; to evaluate this risk for acceptability; and, if therisk is not acceptable, to determine a mitigation strategy. Later, after the necessary Y2Kchanges have been made, the tester must then determine if anything was broken by themodifications, called regression testing, and must validate correct Y2K operation bytesting the software or system in a "time-advanced" environment. A number oftests are required, at least one at each of the identified critical dates and one for eachrelevant date horizon at each critical date.
The emphasis of Y2K testing should be on functional tests. Such tests should exercisethe programs from a real-world perspective while addressing the most critical,highest-risk business functions. Code with the greatest date sensitivity and businessimpact should get the most attention. Functional testing focuses the testing effort ontesting the most mission-critical areas of the code using the "critical datetransitions" listed below in a manner that matches actual software usage before andafter January 1, 2000.
For a software program or system to be Y2K-compliant, it must correctly process datesbefore, during, and after January 1, 2000. This means that from the time the softwareprogram or system is declared Y2K-compliant until January 1, 2000, it must correctlyprocess dates that are on either side of the millennium point. It must correctly processthe transition itself (Midnight, December 31, 1999) and, after the century transition toJanuary 1, 2000, it must continue to correctly process dates on both sides of themillennium point. The software also must recognize the Year 2000 as a leap year, acceptand display dates unambiguously, and correctly process logic dates that are used for"non-date functions."
The software or system must operate properly and provide correct and unambiguous dateinformation as it encounters other critical date transitions. Critical date transitionsare those for which evidence, either hard or circumstantial, exists that date-relatedprocess might encounter error. Some examples of critical date transitions are:
- December 31, 1999 to January 1, 2000 the Y2K transition date
- February 28, 2000 to February 29, 2000 the Y2K leap-year transition
- February 29, 2000 to March 1, 2000
- December 31, 2000 to January 1, 2001
The above are the minimum set of critical date transitions for which tests will berequired for all software and systems being evaluated. Other critical date transitions mayexist for specific software such as some financial systems, or others that work withfiscal years. These may be date sensitive to the fiscal year rollover. For systems thatfollow the Government fiscal year, the following additional date transitions should beconsidered:
- September 30, 1999 to October 1, 1999 the fiscal Y2K transition date
- September 30, 2000 to October 1, 2000
Systems that follow different fiscal years should adjust the above dates accordingly.
To be Y2K-compliant, the software being evaluated must receive, calculate, display,print and store dates unambiguously. This means that the software program or system mustaccept date-oriented input and interpret it correctly. It must provide date-related datato the outside world in a format that is at once acceptable, understandable and correct.And it must display and print and date information in a fashion that is understandable andunambiguous to its users.
Questions to ask include: Where are dates accepted as input? How are dates stored bythe application? Are they stored as dates or strings or...? Are there conversion functionsto go back and forth to other date storage locations? What date calculations areperformed? Is there a leap year calculation function? How are the dates formatted fordisplay? What are the rules for converting both to and from two digit years? Do users orthe system ever enter a special date that has an understood meaning different from anactual date, such as 9/9/99?
The driving motivation behind a Y2K testing strategy recognizes that, with time runningout not all testing projects can be given equal time and emphasis. High-risk systemsrequire more extensive test data development, regression (functional equivalency) testingand certification with an emphasis on special case testing. Special case testingensures that key business dates in 1999 and 2000 are accommodated in a combination oftransactions and situations.
To maximize their testing effectiveness, testers should set up test environments withthe capabilities required for date-sensitive testing, such as the ability to set thesystem clock to future dates. Using date-simulation tools to perform simulated Y2K testingis much simpler than setting the actual system clock, which requires careful coordinationamong testers and solving license, password and security issues.
Summary and Conclusion
Special care must be taken to exhaustively test mission critical applications to makesure they will behave correctly after implementation. This is especially true when filesare expanded and the chance for introducing new errors is much greater. Even conversionsusing the procedural method need to be tested with aged data to ensure they will workproperly in the year 2000.
Even with all this focus and investment, most organizations will find that only aportion of their current operational systems, probably the most critical will actually beY2K-compliant on January 1, 2000. The utilization of a triage strategy will allow anorganization to segment their operational systems: saving the most critical, delaying Y2Kwork on the less important, and retiring the unsalvageable. When the year 2000 actuallyarrives, the workload associated with its arrival will continue to exist throughout thefirst decade of the 21st century. At least part of the problem will remain unsolved (orthe solutions untested) as the clock strikes January 1, 2000. In spite of having investedroughly $600 billion worldwide on Y2K by the end of 2000, a significant portion of thetotal Y2K compliance effort still lies ahead.
About the Author:
Jack W. Wood is Director of Marketing for Formula Consultants Incorporated.