Subject: Re: Y2K Testing article wanted
Date: Fri, 27 Nov 1998 00:39:39 -0500
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
>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:
- the offset of the field from the beginning of the record
- the format of the field
- 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.