Please, Cory, Ed, some Polly, some prog with experience on this issue, Pahlease "disprove" or discount what this consultant here says. Otherwise, I may be going to Sam's for a lot more rice and beans this weekend. Serious. And I already have a lot of food. It is time to stock up for the neighbors. I don't think I could shoot em.

and please Pollies, it isn't relevant that this was posted on St. Gary's sight, nor can what he says be discounted soley by the fact that he is a consultant, and gets paid to give these kinds of warnings. Please stick to the "facts" of the warnings, especially looking at the validity of his time estimates for fixing non-tested systems.....

The reports that say only 50 percent of sites worldwide are conducting effective 20xx testing have generated some significant concern. Our own experience supports these findings. Our experience indicates typical testing plans at sites with significant vulnerabilities are inadequate for their risk profiles. Such plans are frequently adequate for sites with moderate and low-risk profiles. Implementation may be another matter.

Its much harder and more expensive to age data to test a sufficient number of future date scenarios than anyone anticipated. Even then, you cannot know youve tested enough scenarios to protect the integrity of the affected programs and databases. If only we had a magic strategy that didnt require this expensive 20xx testing.

Dynamic date aging is a solution to this problem; it eliminates the need to age the data for 20xx testing. However, the Information Technology (I/T) staff at many sites are under so much pressure that theyre unable to even consider significant advances in testing technology, regardless of potential benefit.

Why is 20xx testing so important? After all, if the programs are repaired and back in production, isnt that good enough? Early results from code inspection projects and our own testing projects indicates that the residual fault rate after 19xx and 20xx testing for a well-done project should be on the order of one fault per 10,000 lines of code (LOC). For planning purposes, we presume the rate will be one fault per 1,000 LOC if 20xx testing has not been done to any significant extent.

Lets do some arithmetic. If your site has 10,000,000 LOC, then without 20xx testing, we presume therell be 10,000 undetected residual faultsas opposed to 1,000 with extensive (and expensive) 20xx testing. If it takes, on average, one day to diagnose and repair one fault, youll have 10,000 days of work to perform when the failures begin to turn up, as opposed to 1,000 days. If you have 100 programmers, your systems will be seriously affected for 100 days instead of 10 days, and probably somewhat impacted for two to three times that long. . . .

On the other hand, a single fault can halt or cripple your processing for weeks. If you test extensively using conventional 20xx testing, you still have the risk that a single fault can result in massive disruption, but the risk will have been reduced by roughly ten-fold. . . .

More important, your survivable downtime will vary. Weve seen government agencies and insurance companies that can survive 100 days of downtime; weve also seen banks and brokerages that cannot survive 100 hours of downtime. The rate of testing in highly vulnerable enterprises may be better than the average site, but the ones weve seen are still not testing proportionately to their greater risk. As a result, we dont share the prevailing optimism in these sectors. . . .

Luck will be a more important factor than many people realize. Lucky enterprises will fail to do sufficient testing and make it through. Unlucky enterprises will spend a lot of money and expect to be fine, but still sink. Living in a rational, digital age predisposes us to think random factors wont have a significant effect. The complexity of Year/2000 will introduce more random factors than weve seen in our lifetimes. Fortune will indeed smile on many, but not on all. . . .

About the Author

Don Estes is chief technology officer of 2000 Technologies Corporation, which was founded to commercialize his technical designs for Year/2000 automated testing and rapid remediation. In addition, he serves as Year/2000 advisor to the State of Rhode Island and is a member of the Cutter Consortium.

-- Walter Skold (wsvnsk@juno.com), October 01, 1999

Answers

Walter, don't hold yer breath....

Owl

-- owl (b@a.com), October 01, 1999.

Walter,

Here is some information the the Institute of Electrical and Electronic Engineers had to say about this topic.....

Basically the last 10% of the remediation project ( testing ) will take 90 % of the time. test/detect error/repair/retest.

url...http://www.ieee.org/organizations/tab/Y2Kfocus.html

Select the topic " Background Breifing " This article tells it like it is.

-- kevin (innxxs@yahoo.com), October 01, 1999.

Isn't Ed (Yourdon) one of the founders and partners of the Cutter Consortium?

-- Chris Byrne (cbyrne98@hotmail.com), October 01, 1999.

It all depends on whether you buy these statements:

1)Early results from code inspection projects and our own testing projects indicates that the residual fault rate after 19xx and 20xx testing for a well-done project should be on the order of one fault per 10,000 lines of code (LOC).

I have no idea where/how they came up with that 1/10,000 figure, but I'll let that go. The point is, the same could be said of ANY good sized "well-done project", not just the Y2K project. (And BTW, does every one of those 10,000,000 LOC involve a date field???)

2)For planning purposes, we presume the rate will be one fault per 1,000 LOC if 20xx testing has not been done to any significant extent.

Whoa, this guy's telling me that he has a test scheme that will find TEN TIMES as many errors as normal testing?! Sorry, but this just doesn't fly, and everything else he has to say is moot.

Let's just say, in my experience, that normal testing scenarios might find ~75-80% of bugs, and more rigorous specialized testing might find ~90-95%. Agree or no? Anyone care to play with those numbers?

3)Don Estes is chief technology officer of 2000 Technologies Corporation, which was founded to commercialize his technical designs for Year/2000 automated testing and rapid remediation.

Oh, that explains it, he's trying to sell his magical test tool. File this under "Sales Crapola".

RC

-- RC (randyxpher@aol.com), October 01, 1999.

(1) RC - I'll agree that perhaps 25% of bugs will be left after minimal testing (which is about what most system remediation gets!), and with difficulty, that can be dropped to 5% or less...

(2) I also noted the source...but another article did tell about a 50% test rate in Great Britain. I suspect that inadequate testing in 50% of the remediated systems is probably about par. For those still being remediated, it will be worse. This based on my 1/3 century in IT.

(3) I don't feel that laying additional supplies is a misplaced activity at this time. I will be shopping tomorrow, as well...

-- Mad Monk (madmonk@hawaiian.net), October 01, 1999.