I have just read two postings, the interview on May 10 with Capers Jones (posted by Dennis on May 15) and the NY Times article on the CAP Gemini survey (posted by Slightly Dubious on May 17). Both are excellent postings, and beat the living hell out of those whose authors have clearly gone off their meds.

So what I am about to say is not a criticism of these two post-people, but rather a remark as to how the material itself could have been made better, which is: There is a particular time-frame which I keep looking for and not finding. The crucial date, it seems to me, is the transition from the end of implementation to the beginning of comprehensive testing. For any organization, I would first find out what method of remediation it has chosen (windowing, etc.) since there are different implications for testing. Then I would find out when they made the transition or whether it is in their future. If an organization feels that they can surely finish implementation by the end of this September and that that gives them a three month cushion, I would disagree. If they meet this deadline, it gives them a scant three months for comprehensive testing. So in questioning all of these organizations, if they think they will make it, this transition date should be homed in on.

-- Peter Errington (petere@ricochet.net), May 18, 1999

Answers

You may be thinking of an overall testall environment, but any program worth his/her salt would be testing along the way. y2ka0k justthinkin

-- justthinkin com (y2kaok@justthinkin.com), May 18, 1999.

justthinkin: A programmer doing his own unit testing along the way won't cut it in this case. (Nevermind that a programmer is the worst person to test his own code change, because of inherent bias.) Peter is talking about comprehensive end-to-end testing that is paramount after such an enterprise-wide code change.

Consider if a company did have only three months for such testing and found several problems after one month of such testing. Coders get under the hood to fix the problem. Presto, chango -- you've just introduced new risk. Guess what? Much of the testing will have to be re-done at that point, with only two months left, to verify that the problems were resolved and no new bugs were introduced.

-- Codejockey (codejockey@geek.com), May 18, 1999.

In one org I worked for, the programmer and contractor were allowed to test their own code because we were kind of off on our own and nobody in the rest of the org understood what we did. But the user ALWAYS got to put a couple orangutangs - - errr- - data entry folks on the test partitioned system to bang at it for a week or so just to validate our tests. 'Course, the test set and strategies were CAREFULLY constructed to test as many of the caes and features as possible BEFORE the oragutangs got to it. Bassicaly the Boss on the user side was a B@#$@RD and LOVED to catch us, so it was part of a game.

In another org, the managers would pick someone from a different part of the shop, hand them the SPECS and say "Go thou and test this. Return in a week," and we'd get a report back in about a week. Before, of course letting the user area work it over.

Chuck

And testing where I was was about 20% of the whole job time, but we were NOT working on huge systems, and Implementation usually took a while (roughly 5-10% of the job time). 'Course, I may be the only living Analyst to bring a Government job in on time and on budget (well 10% high but that was what you shot for if the Feds were paying with a Grant).

C

-- chuck, a Night Driver (rienzoo@en.com), May 18, 1999.

Peter, I'd have to agree with Chuck on this one. In addition, I would add that IMPLEMENTATION implies that a system that communicates with another system has already been tested WITH that other system.

I would further add that my experience IS on big systems. The users are always given a period wherein they bang on the system in the test environment and report any problems. Of course they bang on the "online" system. The batch reporting is where they didn't bang, but these programs could/should also be tested prior to implementation AND the results provided the users for analysis.

It doesn't ensure that things won't be missed, but it sure reduces the likelihood.

Anita

-- Anita Spooner (spoonera@msn.com), May 18, 1999.

I believe I made a valid point, but apparently I used confusing terminology (i.e. my use of the word "implementation".) Of course unit testing will have been done. By comprehensive testing, I meant what Codejockey describes.

-- Peter Errington (petere@ricochet.net), May 18, 1999.