Checklist: Year 2000 Issues
| Don't change anything else. | There is a management tendency to request additional changes while you are "in the code." If you are asked to change anything else in the system, offer to investigate and document the change as much as possible, but stay away from additional code changes that will require testing. |
| Don't wait for the new system. | You may be told with great confidence that a particular program may be ignored because a new system is being developed. (Probably scheduled for implementation on 12/31/99.) Make a contingency plan and be prepared when you find out that the new system is delayed. |
| Improve the documentation. | This may be the ideal time to review documentation. It is probably not the best time to make major updates, but at least use a checklist to identify omissions and discrepancies that can be handled later. |
| Record the modification procedure. | Record all of your activities to assist the next person modifying the system. (It may be you.) This would also be an excellent resource to locate defects found in testing. |
| Communicate. | Be certain that QA and development activities are coordinated. |
| Use a project management tool. | This is a great opportunity to introduce project management software, if it is not already in use. Record all review, testing, and programming activities. |
| Develop a unit test plan first. | Write a basic unit test plan for developers before any coding begins. Most of this test plan can be boilerplate, because nothing else is changing but the date format. |
| Develop a system / acceptance test plan before any coding changes. | The formal review of the test plan will provide insights for QA and development. Include customers in these reviews. |
| Prioritize changes by impact to the organization, not ease of change. | Review the criteria that are used to sequence the changes. |
| Do regression testing. | Regression testing will increase your confidence level that changes to the system will have no negative consequences elsewhere. Remember that date changes on reports may not require full regression testing as they sit on the periphery of the system. |
| Leap year. | The year 2000 is a leap year, 2100 is not. |
| Use a data dictionary. | Use (create?) a data dictionary to ensure that proper variable names are selected. This is even more important if you are not performing full regression testing. |
| Use a traceability matrix. | This may not be the best time to build a complete traceability matrix, but it is a good time to get started. The matrix will allow you to trace all of your tests back to specific requirements. |
| Regulatory requirements. | Meet all of your regulatory requirements for modifying a system. Review your ISO 9000 procedures. |
| Time Zone. | Remember that the switch to year 2000 takes place 24 times or more for multinational organizations processing in multiple time zones. |
| Software leases. | Talk to your vendors before you change the date to January 2000 for testing. If you don't, you may find a message on the screen telling you that you have not renewed your lease. Your software may be automatically disabled (and changing the date back to the correct date will not fix it). |
| Testing partitions. | You may need to establish additional
testing partitions to manage Year 2000 testing. Be especially careful if you
are using live data. While this is never recommended, there is a particular
danger of changing dates, accessing a file, and then resetting the dates. Remember that all data must be appropriately aged before testing. It may be necessary to set the clock/calendar forward on more than one machine (especially the file server) when testing in multi-user environments. |
