Y2K Testing Article
Home Up Y2K Testing Article Regression Testing Data Aging PCs

 

Subject: Re: Y2K Testing article wanted
Date: Fri, 27 Nov 1998 00:39:39 -0500

Jerry,

With time pressures as you express, there is no way to complete a formal article by mid-December. Perhaps you would accept an email with your outline (and consider it like a mini-article)

>1. The items to be tested.

A set of output files which results from execution of a computer application being tested for Y2K compliance. It is expected that the input files to a computer program has been aged from some base set of files using a data aging tool.

The files being tested by this tool may be report files or data files.

>2. General Y2K testing technologies review.

The purpose of Year 2000 testing is to see that code which currently works in the year range of 1900-1999 will continue to work in the same manner as we cross the century boundary and into the next century.  There are two basic ways to accomplish this.

First, one may set up an "empty" set of files, enter transactions and manually check the output for correctness. Here the movement of the system date is accelerated at a faster pace than a normal date (such as the system clock is moved ahead one week at the beginning of each day).  The system clock for this test cycle my begin on December 1, 1999 and end in March of 2000, or whatever dates are appropriate for the system.

This first process is manually intensive and tends to be heavily based on "luck" rather than thorough testing of the most widely used functions.

Second, one may take an existing set of files, and use a data aging tool to move the base date of the files to various dates, execute the program and compare the output files with the output files from earlier tests.

>3. The problems existing in the common testing tools.

There are many tools available for aging data and some available for comparing the output of aged files. Any aging tool may be used with most any comparison tool.

All other comparison tools require an extensive amount of setup work to compare files. The programmer must identify three items related to each field:

  1. the offset of the field from the beginning of the record
  2. the format of the field
  3. how to tell one record type from another in the same file. (Note that, in the case of a report file, it may not be possible to distinguish one record type from another. In that case, the other comparison tools may not be able to be used for performing the comparison. It may be left to a manual process.)

>4. Your special solution.

DateWise FileCompare has a patent pending process which automatically reconciles date fields which changed in files between the program executions. The tool does not even have a method to specify the offset, format or record types of any specific field because it is not necessary. The result is a tremendous savings in setup times and the capability to compare files which otherwise may not be comparable by software.

These claims can be verified by requesting a demo, completing a non-disclosure agreement and using your own test files to verify the process works.

>5. The advantages of your solution.

There is little or no setup to use the tool to use this tool.
The only required fields are the locations of the two files being compared. It is not even necessary to tell the computer what the difference is between the two files, though specifying a difference allows the computer to provide a more thorough report of where the variances are in the file. There are a couple dozen possible optional command line parameters (though it would be rare to specify more than five optional parameters in a single comparison).
It is capable of comparing files not otherwise comparable using automated tools such as report files.
It is more accurate than manual comparison of files (required for certain types of files.
It works with files separated either by a quantity of days or quantity of years difference.
It handles comparisons automatically even if the date format has been changed between executions, such as changing MM/DD/YY fields to YYYY/MM/DD.

>6. A case study to explain your solution in details.

A company wishes to verify its Y2K compliance. It purchases a data ager and carefully examines the input file structures of its files.  Each date field is identified to the data ager by (1) location, (2) format and (3) record type. This information is laboriously entered into the data ager.

Initial production data is captured for the runs on December 13, 1998 along with all the updates electronically done to the data files for the following week. This process missed the online transactions, but the company receives equivalent transactions to most of these online transactions from its interface partners. All the data files are aged to August 3, 1998 (by subtracting 133 days from every date in the file).  The resulting data input files are run through their computer system (using a date simulator to set the system date to August 3, 1998).  Approximately one out of every fifteen records is rejected by the computer because the timing was incorrect for that type of record to be processed. These details are all problems that happened because of their aging process and have nothing to do with the DateWise's tool.

This August 3rd run will be considered the "base" run against which the other will be compared. The reason for selecting this date is that it parallels January, 2000 (same number of days in the month and days fall on the same day of week). In fact, there is a parallel time period of many months which these two time periods parallel, differing by 437 days.

The input files that was used for the base run are aged using the data ager by 437 days into the future. The program under test is executed (with the system date now set to January 3, 2000) with the new (aged) data as input. The same records kick out of this run, as kicked out in the base run. The output files are expected to match with the exception of the dates.

Enter DateWise FileCompare tool. Each of the output files from the base run and the January 3, 2000 run are compared using DateWise's tool without any additional setup and specifying that there is supposed to be 437 days difference. All files are compared, including report files.

A second test is planned for testing leap year processing. The same process is followed. A base file set is captured on December 29, 1998.  That data is aged 437 days (to February 29, 2000) and compared with the output from the December 29, 1998 run using DateWise FileCompare without doing any setup on the comparison process.