Patricia Ensworth

Would now be a good time to ask for a raise?

Like all occupations, software testing has a hierarchy. The higher up you go, the wider your range of vision — and your accountability.

Most testers are cautious, empirical people by nature, so when asked about the progress of our Y2K efforts, we usually answer according to our personal experience. In organizations where the testing began years ago and resources were plentiful, you’ll find junior and mid-level testers saying that, yes, things are under control. But no matter how forward-thinking, well-managed or lavishly funded his or her information technology department, I doubt there is a senior Quality Assurance (QA) manager anywhere who doesn’t occasionally wake up at night with a panic attack over some rogue variable.

To understand why this is the case, we’ll have to go behind the scenes of the Y2K testing efforts at your average medium-sized American business. I’ve created a composite view-from-the-cubicles of Everycorp, Inc., pieced together from a number of testers at companies, agencies and nonprofit groups in different industries and regions.

Let’s assume that we’re in a U.S. business with operations in Europe, Asia and Latin America. We’ve got mainframe systems, client-server databases, Web sites and a multitude of employee-created Word templates, Excel macros and Access databases filled with date fields.

The tale begins in the spring of 1997. Everycorp’s information technology staff is busy with the usual crises: system upgrades, viruses, unreasonable demands from the marketing department. A developer receives a promotional copy of a magazine about Y2K problems and circulates it. A tester attending a QA conference hears presentations by testers from international banks and brokerages about their Y2K compliance projects and fires off a nervous e-mail to the entire department. The department manager goes to an expensive seminar sponsored by a revered management consulting group and decides the entire Y2K problem is a scam. Meanwhile, everyone’s attention is riveted by a new phenomenon called the World Wide Web.

Fast-forward to Thanksgiving. It’s now budget season, and managers are arguing over how to slice the 1998 pie. Senior management, through its mysterious golf resort and boardroom grapevine, has heard that the Millennium Bug could put us out of business. A decree goes forth: All critical systems shall be compliant by 12/31/98. Funds are allocated. Objectives are set. The organization springs into action.

A Y2K product manager is appointed. This ambitious individual possesses a snazzy wardrobe, the stamina for endless meetings and a penchant for writing voluminous reports — and is not sorely missed by software developers actually doing work.

The legal department agonizes over definitions: What is the difference between “Y2K ready” and “Y2K compliant”? The lawyers determine which dates need to be tested and certified. (Not just 1/1/00, but 2/29/00, and many others.) They prepare lists of documentation testers must submit to prove that Everycorp’s systems have been tested.

Corporate Communications arranges for employees to receive a daily news feed of alarming Y2K articles from the world press. They prepare guidelines for how to speak to outsiders about Y2K. Basically (just in case a stray investor, regulator or member of the press might be listening), they want the dialogue to go like this:

Concerned Citizen: So how’s the Y2K bug going to affect you at Everycorp?

Tester: It’s not. We’ve almost finished testing. All our mission-critical systems run fine.

Concerned Citizen: Really? Already?

Tester: Sure. We expect to be done by the end of 1998.

Concerned Citizen: Wow. What a great company.

Back at ground zero in the software development group, project managers adopt different approaches to the situation.

Some take a look at their code and quit immediately. Others take advantage of the generous Y2K budget to buy hardware and schedule software enhancements that have nothing to do with the Millennium Bug, figuring that senior management will never know the difference. Some managers roll up their sleeves and get to work. Others hire consultants.

One such specialized Y2K consultant arrives on the scene. According to a sales pitch, his automated code review tool can plow through a C++ or VB system identifying trouble spots at lightning speed. The consultant is given a minor system to review, and a few weeks later he sends a report. A review of his findings turns up serious omissions. The consultant is grudgingly mailed a six-figure check and not invited back.

Another project leader hires a retired COBOL programmer. Actually the programmer didn’t exactly retire — he was laid off in the 1980s and has been scrounging for work ever since. With the advent of the Y2K frenzy, however, his life has turned around. He has paid off his kids’ college loans and bought a vacation home with cash. He dives right into the ancient code and not only locates the bad date fields; he also fixes irritating bugs and nagging design problems that have been driving users crazy for years. He holds grandfatherly court in the lunchroom, surrounded by Gen-X Java-coding acolytes who come to him seeking wisdom on systems development methodology.

And so 1998 passes. Has the IT department at Everycorp met its Y2K objectives? On paper, yes. But bear in mind that managers who don’t meet objectives don’t receive bonuses. We can assume Y2K compliance has been met in all critical systems, except for those: A) whose managers lied, or B) whose managers reclassified their systems as noncritical to get a postponement.

Now it’s 1999. Even if all of Everycorp’s critical systems were certifiably Y2K compliant, there’s still plenty to worry about.

First off, the international offices. Originally these were scheduled to be part of the 1998 testing, but there were local languages and time zones to navigate. And the international staff really didn’t seem terribly concerned.

In Latin America, local employees claim that if anything goes wrong, they could get by with the old pencil-and-paper recordkeeping. They figure their customers have lower expectations for efficiency.

In Europe, local staffers were too busy with the euro to give Y2K much thought. Besides, they can’t quite understand their American colleagues’ agitation. After all, once you’ve lived through two world wars — cities leveled, populations starving, orphans shipped overseas — what’s so terrible about a computer shutdown? Probably less of a hassle than a French truckers’ strike.

In Asia, memories of disaster and turmoil have not bred complacency. Y2K tests are carried out with a degree of precision that could shame many an American tester. However, there seems to be less concern about robust technology than customer relationships. Looking to Japan’s 1995 Kobe earthquake, when the president of the local telephone company visited customers’ homes to personally apologize for interrupted service, Everycorp’s Asian managers apparently are preparing to perform similar acts of contrition in January.

Then there’s the matter of ongoing compliance. Everycorp’s critical systems may have passed Y2K tests as of 12/31/98 — but those systems are going to change. How many business users are willing to wait more than a year for a bug fix or enhancement? With each change, system tests must be run again.

Finally, let’s suppose Everycorp’s IT department is outstandingly hardworking, excruciatingly meticulous and just plain lucky. By December 31, 1999, it has tested all systems and confidently awaits the new millennium. Yet the senior QA manager still can’t get a good night’s sleep. In his nightmares, monsters slither in through the modems. Unlike banks and stock exchanges, Everycorp has not participated in industry-wide data flow integration tests. Who knows what evil lurks in those innocent-looking data feeds?

Many testers are far too down-to-earth and skeptical to believe the doomsday scenarios that impel others to buy survival gear. Still, the chance that any of the dire predictions might come true is enough to sharpen our resolve, as we scarf down another takeout dinner in the conference room.

Every so often we’re struck with awe at the scope and import of the project we’ve been drawn into — something much stranger and more profound than debugging date fields. We know for certain that some systems are going to fail. In evolutionary terms, it’s as if we could see a mass extinction coming right at us, yet nobody can predict which species will succumb.

Naturally Y2K testers want to do whatever they can to secure their own future. Yet balancing the survival-of-the-fittest spirit is the realization that no system of any consequence is entirely self-sufficient. We are connected. Every tester working on the Y2K project experiences a particular moment of combined fear and elation as we discover how interdependent our programs are. Each embedded link, each data feed, each pointer to an external Web site takes our code across a border into someone else’s territory.

Taking part in a planet-wide effort to preserve our technology can be quite inspiring. My 11-year-old son sees it in swashbuckling terms: What if the Earth were invaded by aliens who tried to destroy our civilization by sabotaging our computers?

The truth is that underneath our professional pessimism, many software testers are idealists at heart. We want reliable information systems in the same way that Public Citizen wants safe consumer products and Amnesty International wants human rights. The Y2K effort has made it a good time to be a software tester because, in spite of the workload, we know what we’re doing matters.

We have no better idea than anyone else what will happen on January 1, 2000. But you can bet on this: Next spring we’ll be enjoying a well-earned vacation.