By Jeff Gainer
(Author’s note: This article appeared in the August 1998 edition of the itmWeb Report.
If anything good ever comes of the Year-2000 boondoggle, it will likely be a greater degree of attention and respect for software testing. A number of years ago, after writing my first software application, I expressed concern to the government agency whose databases my system accessed that their data tables had only two-digit year fields. I had managed to work around the problem for the time being, I noted, but innocently asked, "What are we supposed to do in sixteen years?" The reply was considerable amusement that I would worry about something so far in the future. After all, I was told, the whole software application would be replaced long before 2000 A.D.
And at last report, the software system has been replaced, indeed, even updated several times for new platforms, but alas, the two-digit years remain in the database.
The rise of rapid application development (RAD) and its love child, Frantic Application Development (FAD) spawned the trend toward no requirements, at least no written requirements. In many RAD development shops, testing is viewed as the final step in the software development life cycle. After a peculiar fashion, the software is developed, thrown over the wall to an ad hoc test team consisting of junior developers, clerical workers and a few business domain experts who happen to have a little free time. In this environment, everyone plays around with the product, tries a few actual user scenarios, and otherwise "tests" by generally poking around for the few weeks allotted to "testing." The results are predictable: a few enhancements are suggested, a few glaring bugs are identified, and the product is somberly deemed "tested" and thus released to the hapless beta testers.
Today however, there is finally a serious trend toward treat software testing as the legitimate sub-discipline of software engineering that it rightly is. The industry (and our customers) have now become acutely aware that the Year-2000 problem is not confined to aging mainframe "legacy" systems, or buried in arcane or lost source code and yellowing project documents. Our legacy systems are aging, undocumented database tables lurking deep within webs of interdependent systems. Moreover, these noncompliant data definitions have spawned their own problems, encouraging time-pressured RAD developers to code around their non-Year-2000 compliant formats, exacerbating the problem.
If we had only tested these "non-critical" systems for Year-2000 compliance sixteen years ago--but then, such a jejune notion was considered merely amusing.
Copyright 1998, by Jeff Gainer