This has probably been rehashed on the Forum, but how can dgi's and pollies, especially programmers, be confident we won't face many failures given the testing issues below. Of course, they will say this informtation is provided by a company that wants to sell services. Hey, would selling cement to people with holes in their dikes be an immoral act? People sell you the food you eat to live? So get off that lame excuse. So, for anyone who wants, how about rehashing this testing concern, or just posting where it has been debated previously.

---------------------------------------------------------------------

What Makes Year 2000 Testing Different and Difficult?

Randall W. Rice, CQA, CSTE

At first glance, it would appear that Y2K testing is like any other kind of test for legacy systems. However, there are some issues that distinguish Y2K testing and make it very challenging to say the least.

7 Huge scope

Many organizations have hundreds of systems representing millions of lines of code. The sheer size of the project forces many people to test only the essentials.

7 High complexity

While testing each software unit alone might not seem too difficult, it becomes a much more complex job when interfaces between units and systems are considered.

7 Poor or Non-existent documentation

Because of this lack of documentation, it is difficult to know what to test.

7 Non-standard date routines and other software operation

People are discovering all kinds of bizarre coding practices while renovating and testing legacy code. For example, some date fields do not contain dates at all, but other flags and data.

7 Need for a special "time machine" test environment

Test environment considerations for Y2K are often difficult to address. To test for the first point of Y2K compliance, you need to test with a system date in the year 2000 or after. In most cases, this requires a special segregated test environment.

7 There will not be enough time to completely test everything

Most people will be doing well just to test the essential Y2K test cases. Complete functional testing will become more difficult the later testing begins. This increases the risk of regression defects.

7 Test data must be "aged"

There must be a way not only to advance dates in the test data, but to do so in such a way as to maintain correct date relationships within the file and with other data sources.

7 Multiple cycles of testing are needed

To simulate date rollovers and business processes, multiple cycles of testing will be needed. This implies that Y2K testing is not just a matter of testing one program or a set of programs in isolation.

7 Lack of an existing baseline

Very few people have an existing baseline or test bed of test cases and test results. To perform regression testing, a test of the existing system is needed for a comparison. It takes time to build such a baseline and many people will likely compare 20th and 21st century test cases using already converted software.

Taken from the course, Testing the Year 2000, Rice Consulting Services, Inc.

Randy Rice is a writer, trainer and consultant in the field of systems testing. He can be reached at rcs@telepath.com.

Back to Articles Page

Back to Year 2000 Information Page

Return to Randy Rice's Software Testing Home Page

) Rice Consulting Services, Inc. 1995-1998. All rights are reserved. Questions and comments should be directed to Randy Rice at rcs@telepath.com.

Rice Consulting Services, Inc. P.O. Box 891284 Oklahoma City, OK 73170 405-692-7331 405-692-7570 FAX

-- walter (wsvnsk2@juno.com), November 08, 1999