Återigen ett återgivande av ett brev som skickades till Gary North från en programmerare. Testfasen är den viktigaste och största delen av arbetet mot y2k-compliance.

Testing Is Crucial, but It Is Not Being Done: A Programmer's Testimony

For the past 6 months, I have been working as a mainframe system tester on a Y2K project for a large international company. Let me share with you my experiences to illustrate why testing is so important and so time-consuming...

I was brought onto the Y2K team as a consultant in March of '98. The team at the time was 4 people, including myself. It took me a month just to get up to speed on their operations. Needless to say, it is quite complex. I could only learn the mainframe side, and only a small part of it. They use hundreds of programs and have roughly 1 million lines of COBOL code. My responsibility initially was to create a full Y2K "testbed" of data using a variety of date scenarios and testing the full functionality of the system (touching every date-related program). This was a large task as well. Prior to my arrival, my employer had contracted with another company to identify all of their date-related code, and implemented a windowing technique to fix it. Sixty-seven programs were modified, and the code was immediately put into the production environment without testing. This is common practice amongst mainframers.

As I became ready to test, there wasn't a test environment set up to work in. Because the developers put their code immediately into the production environment from the development environment, they did not have an active test environment. When that was available, days later, there was disagreement about methodology. After numerous meetings and some general agreement, there was suddenly dissention. How much field data should we use? I argued that we would need to submit at least 12 sets of data to simulate monthly data. I felt this was the only was to accurately test monthly, quarterly, and annual reports. That was overruled as "too much work". Instead, one day's data was chosen, and it was aged repeatedly. The plan was to test 4 dates only (again, to save time and effort): 12/20/99 (baseline), 12/31/99, 1/1/00, and 2/29/00. Far from comprehensive, but it would suffice.

My employer's original stated goal concerning Y2K was to have all "mission-critical" programs tested and compliant by 12/31/98, with non-mission-critical completed by 2nd quarter of '99. In July of this year, upper management, seeking a competitive advantage, changed all the rules. Now ALL applications would be tested and compliant by 12/31/98!! No leeway, no fudge factor, just DO it!! Several other consultants were brought in to work on projects which were originally scheduled for 1st quarter of '99. No project plans were in place. No test environments or databases had been created. All of these things are necessary and time-consuming for thorough, well-documented testing.

Once testing began, there were numerous problems. When the system date was changed on the mainframe (this is, by the way, not as easy as changing the date on a PC--it takes approximately an hour to do), immediately all passwords had expired. No one had even thought of that! That wasted a day. It was the first of many wasted days. As the testing effort continued, there were numerous abends (program terminations) for a variety of reasons. Because only a subset of programs was being tested, the JCL (Job Control Language) needed to be modified. There are errors inherant in this process. It was determined that our department would require approximately 300 tapes to store data files. There was argument about whose budget that would come from. Meanwhile, the operations team lost their most experienced operator (20+ years of experience), as he joined our Y2K testing effort. Lots of bad blood and lack of cooperation from operations ensued. The developers also viewed this whole project as a nuisance. They were certain the code worked (as most programmers are), and they had more pressing duties every day with production fixes or problems. The lead developer (30+ years experience) missed several days when his father died. Noone knew what he does (a very frightening thought, but it is not unusual), so everything ground to a halt. When we resumed, he discovered that our original baseline date needed to be changed because field offices use week-ending dates that are 2-3 weeks in the future on occasion, which meant that our baseline included dates into 2000, which we wanted to avoid. Once that was resolved, programs which had been written to compare the baseline data to the other data files blew up. It wasn't clear why. Programmers with many years of experience needed several days to try to find the reason. Then it blew up again for an entirely different reason, which was apparently related to date-handling. I was unable to view any reports, as only data files were being compared initially.

I could go on and on. Bottom line? After 6 months, we are STILL in the EXACT SAME SPOT as when we started!!! OK, we've learned from our mistakes, but NOT ONE TEST has successfully completed!!!

Is this company unique? No. In fact, their Y2K project, complex as it may be, is peanuts compared to many other Fortune 1000 companies. They have "only" one million lines of COBOL code (approximately double that in total). Also, because their fiscal year coincides with the calendar year, the current year is assumed in most cases. This is why only 67 programs were actually modified. When dates are used as variables within programs, it is usually month and day only. Many companies have fiscal years that do NOT coincide with the calendar year (they start in July or October, e.g.). As a result, the year is almost always needed.

Again, bear in mind that this only simplifies their internal efforts. Compliance, in the full sense, means that they must have compliant suppliers and vendors. Although their goal of internal compliance by 12/31/98 is possible, full compliance will not be. For example, many of their banking transactions are handled via direct deposit. Invoices are sent via EDI. Both the banks and EDI have said they won't be ready for testing (much less internally compliant) until the first quarter of '99. So, as much as claiming compliance might give them a "competitive edge", any claim of compliance will of course be called into question. This is, of course, true for every company in every industry.

Due to the complexity of validating every date in every program and database, testing is absolutely essential. It is by nature time-consuming, and not just for some of the reasons mentioned above. Knowing that half of all companies who are working on a Y2K project will perform NO testing is indeed frightening.