If you have made changes, perform regression testing wherever possible, using the original test scripts for each application. If you don't have access to the original test scripts, you should attempt to test the functionality of the entire application, regardless of whether certain functionality uses date processing. This step is necessary because various changes at any level of the application could have a domino effect (for any number of reasons) on any other application functionality. Testing only the changes is not good enough.
Ensure that all test conditions and the results from all testing are well documented. The testing tasks and issues described in the following subsections might help you formulate your testing plan.
Test the user interface and third-party controls
As I have mentioned, calendar controls are at the top of the hit list for potential Y2K horror stories. There are too many commercial calendar controls for this tutorial to cover individually, and I wouldn't be surprised if many of the existing calendars are updated to new versions fairly soon.So if your application uses a calendar, and even if you have a new Year 2000 compliant version of that calendar, give it a good hammering. Test all conceivable scenarios. Leave no stone unturned. When testing the user interface there are a number of key dates you should test in as many different formats as possible. The table below shows a list of dates that you should use in your testing.
| Valid | Invalid | Ambiguous | |
| Dec 31 1998 | Jan 1 1999 | Feb 29 1900 | Jan 1 00 |
| Feb 27 1999 | Feb 28 1999 | Feb 29 1999 | Jan 1 99 |
| Mar 1 1999 | Sep 9 1999 | Feb 30 2000 | Feb 29 00 |
| Dec 31 1999 | Jan 1 2000 | Feb 29 2001 | Jan 1 29 |
| Feb 28 2000 | Feb 29 2000 | Feb 30 2004 | Jan 1 30 |
| Mar 1 2000 | Dec 31 2000 | ||
| Jan 1 2001 | Feb 28 2001 | ||
| Mar 1 2001 | Feb 28 2004 | ||
| Feb 29 2004 | Mar 1 2004 | ||