Solution Infrastructure:

It's important to take an end-to-end view of Year 2000 testing. There are two dimensions to the Year 2000. One dimension is represented by the technical facets of the problem which are fairly straight forward. The second dimension is the scope one needs to consider which is quite large.

The Year 2000 Problem

• Technical facets:
  • 2 digit storage of dates
  • Incorrect leap year calculations
  • Special functions dates e.g. 9/9/99

• Business Scope:
  • Embedded Systems, Hardware, Firmware
  • Operating Systems, Applications, Custom code
  • Business Processes, Supply Chain

Initial Questions to ask, before any testing is attempted:

Storage:

• How are dates stored by the app (data structure names, types, etc.) What are the logical limits?
• Are there conversion functions to go back and forth to other date storage (e.g., system date, server, à). What are they?

• How are the dates formatted for display?
• Are system calls used for formatting dates? Which?
• If your application "rolls its own" code for display, does it reference any system setting to change display. Where/how can it be changed?

• Where are dates accepted as input?
• Are they stored as dates or strings or...?
• What are the date parsing rules? What are the dependencies for the date parsing functionality (System date? OLEAUT32, reg settings?)
• More specifically, what are the rules for converting both to and from two digit years? What are the dependencies for evaluating those rules?
• Do users or the system ever enter a special date that has an understood meaning different from an actual date, such as 9/9/99?

• What date calculations are performed?
• Are their type conversions required in order to perform the date calculations? Are they consistent with the rules for parsing date input?
• Is there a leap year calculation function? Is it correct (usually small enough to be easily walked through)? Where does it get used? Note for tests later: if serial dates are used, calculations such as adding, subtracting and comparing dates are less likely to be problematic, but more leap year type problems can occur. If dates are stored with separate Month, Day and Year fields, the opposite is true.
• What logic is there for handling date calculations at the limits?

Experience suggests you should examine both the interior code structure as well as exterior behavior. Often it's best to start with code analysis and end with Black Box testing.

An approach used by many effective groups is to:

1. Grep for system date calls
2. Identify all structures used to store dates in the code base.
3. Either code review, or design and execute test cases-or-both, to evaluate behavior with dates across the supported range of dates for all the areas identified by the first two processes.

Test Verification List:

In general there are some areas to consider when testing the Year 2000:

• When testing a platform verify its handling of BIOS errors related to the year 2000. Verify year display in each decade of 2000-2099. If it knows time zones, verify operation when UTC is a different century than local time (both + and - from UTC).
• Test an application with 2-digit date entry and 2-digit date display both before 2000 and after. And when the entry / display is a date in the other century, both before and after.
• Verify entry / display of 4-digit dates.
• Verify sorting of dates where some are before 2000, some after.
• Verify day-of-week before 2/29/00, on 2/29, and after. On 2/1/01.
• Does your program do any "year ahead" calculations? Testing in 1999 may be critical.
• What happens if you're networked to a machine with the wrong year? Or different time zone?
• Can you backup before 2000 and restore afterwards?
• Do you ever select a date range? Can the range cross 2000?
• Did any previous version of the program store data in a file format where 00 or 99 meant something special (e.g. never expire?)
• Find the limits to the date values the program accepts.
• Determine the special test issues for your product (long list)

Hardware and Software:

• 12/31/98
• 1/1/99
• 12/31/99
• 1/1/2000
• 2/28/2000
• 2/29/2000
• 3/1/2000

• 12/31/98
• 1/1/99
• 1/4/99
• 9/9/99
• 12/31/99
• 1/1/2000
• 1/2/2000
• 1/3/2000
• 1/4/2000
• 1/5/2000
• 1/31/2000
• 2/28/2000
• 2/29/2000
• 3/1/2000
• 3/31/2000
• 10/10/2000
• 1/2/2001

10/1/1999: First day of fiscal year 2000 [for many including the US Government].

1/0/2000: To ensure this date is NOT processed [some spreadsheets and database applications do have this problem and count January 0 as a day before the 1st]

1/10/2000: First 7 or 8 character date in YYY/M/DD format (2000/1/10 or 2000/01/10)

2/30/2000 and 2/31/2000: To ensure that this date is NOT processed [found in some PC applications]

10/10/2000: First 8 character date using a 2-digit month (2000/10/10) December 31, 2000: 366th day of the year 2000. This could be a problem for systems that use Julian dates.

1/1/2001: First day in the 21st Century. This is the last leap year related date, testing the first day of January 2001 to ensure it can be set. Overflow for Tandem systems

1/1/2002: Or any other date past this day, to ensure no processing errors occur in backward calculations and processing of dates in the 1980s and 1990s at this point in time

2/29/2001: To ensure that this date is NOT processed as a leap year

2/29/2004: To ensure that this date is processed as a leap year

Or others that you believe are necessary to complete your tailored testing.