There are a number of considerations relating to Y2K testing which can be summarized briefly as "Don't test unless you really have to."

As a general rule, Y2K testing is only justified when the potential research impact of non-compliance is very high and there is no other satisfactory way to determine the compliance or non-compliance of the equipment. Testing of equipment items with low business impact cannot be justified by the potential benefit.

The preferred method of determining Y2K compliance should always be to rely on information from equipment manufacturers and suppliers. Inspection of equipment during ongoing normal operation, to identify the model, manufacturer, etc., cannot cause problems. But intrusive testing (testing which involves changes to the system, such as trying to set the clock date ahead) must be considered very risky. Remember that the Y2K problem may lie deep within the hardware platform. Safeguards built into the system or its application package software/firmware, which normally afford protection from inadvertent or unintended changes, may not themselves be Y2K compliant. Testing should never be undertaken without full awareness of such issues and of possible consequences.

Problems with Testing

Resetting system timers is very risky and liable to produce unpredictable results because:

• Some systems resources and functions are date/time-sensitive and may be activated or de-activated when the system clock is reset.
• System programs designed to handle normally improbable conditions may no longer be available.
• Resetting dates may create problems which application programs are not designed to deal with. An example is that the date shown for the creation of data (source and object code) may be later than the current date. Checks and modifications may be needed to avoid undesirable consequences of this type of problem.

Among the most vulnerable program items which may be damaged or deleted because of false date expiration are:

• User IDs

• Passwords

• Data files / databases, and individual records in them

• Authorization / protection

• Licenses / services

• Network access

• Functions invoked automatically (failure to operate and unexpected operation are possible consequences)

Testing - The Bottom Line

1. Do not employ testing unless it is absolutely necessary.

2. If testing is unavoidable, get technical assistance.

3. If possible, get manufacturers advice before deciding on a Y2K test procedure.

4. Be sure to have a contingency plan for what to do if the equipment fails.

5. Take every precaution to ensure the health and safety of those carrying out the test.