Re: Y2K testing

Speaking from a purely legal point of view, keep your overview documentation as general and vague as possible.

The devil is in the details and the more details you provide the more rope to get hung by.

Now from an IT professional point of view, use all test cases as "exhibits" to the documentation as a demonstration of vigilant effort to assure data accuracy.

Both cases are defensive measures should your company find themselves in litigation.  For damages to be awarded, the other party must prove neglect or intentional disregard for "sound and prudent" practices.

Their first hurdle must be to disprove the general overview, then they must tear apart your exhibits.

This would only (and I must stress "only") occur if they can first prove that they actually were damaged by any flaw in your application.  Inconvenience is not damage.  Or as the old saying goes: "Lack of planning on your part does not constitute an emergency on my part."

The key to backing up your company will be determined by the contractual agreements that you have with your clients/partners.

If the agreement is worded that delivery will be made on a "best effort" basis, they would be required to prove that your company did not perform a "best effort" to deliver.  Such was the case where companies used UPS to deliver goods then UPS went on strike. The sending company would be held harmless for actions beyond their control.  Making a rapid call to another carrier, even if you had to wait two days for pickup, is demonstration of a "best effort".

On the other hand, if the contract has a 12 hour demand of delivery to support a JIT relationship, break out the typewriters and get the product to them! <G>

James W. Kilgore
qappdsn@ibm.net
 

Steve Raisor wrote:

     We are about to start final Y2K testing out our company.  We have already made all the database and programming changes we think are necessary, tested them, and implemented them in our production environment.  The question we discussing is what documentation should be produced out of this process for legal, auditing, and customer purposes.  We are a manufacturing company.    On one side of the discussion, there is the belief that we need a document for each of our applications, describing what processes were tested, the results, and proof that the testing proved ok(ex. printouts), on the other side of the discussion is the belief that a general description of the method of testing, the applications tested, the general results, but no detailed descriptions of the processes tested or detailed results. Any opinions we be greatly appreciated!!Steve Raisor