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

 

Subject: Re: Data Ageing: PC/Client-Server databases
Date: Tue, 01 Dec 1998 00:01:08 -0500
To: year2000-discuss@year2000.com

Lee,

I will take a stab at clearing up your confusion with a simple example.

Suppose you have a spreadsheet that tracks how much leave you have accumulated. Suppose you started work six months ago (June 1, 1998) and have not taken any leave yet. The spreadsheet works by subtracting the date you started working for origin-it from today's date and multiplies the difference by 80/365.25, then subtracts the total amount of leave you had already taken. As of December 1, 1998 you had accumulated 40 hours of leave.

You have just remediated your spreadsheet and want to test it for compliance. If you merely change the system date by 1 year, you can not directly compare your output from the program without intimate knowledge of what the spreadsheet does. If you only change the system date by 1 year, it would tell you that you had accumulated 80 hours of leave.   Since 40 is not the same number as 80, it is hard to compare the numbers.

Now, if you age the data by 1 year, this is what it means. You add a "constant" amount to "every" "date" in the spreadsheet.

The spreadsheet says that you started June 1, 1999 and the current date is December 1, 1999. It still calculates that in the six months you have been employed, you have accumulated 40 hours. Since the non date values all match (in this case, the 40 hours), the spreadsheet worked for the date it was aged to.

That aging didn't really prove very much because it is still doing work in the 19xx date range. If you age it by 18 months instead of 1 year, the spreadsheet would believe you started work on December 1, 1999 and the current date is June 1, 2000. Still, it would calculate that you had accumulated 40 hours. This time though, the spreadsheet had to calculate a difference between dates in two centuries, furthermore, the calculation had to include leap year day.

It would probably also be wise to calculate a scenario where all the dates fall in the next century, so age the initial data by 2 years.  This would result in the spreadsheet saying that you started on June 1, 2000 and the current date is December 1, 2000. Still, the spreadsheet would calculate that you accumulated 40 hours.

So, you see, setting the system date is a part of working with aged data, but not all of it. You also must alter the data itself.

Carrying the example a little farther, there is typically a lot of work setting up a tool to age the dates. You have to tell the aging tool where each date is in the file, the format of the date and how to tell one record type from another.

It is generally as hard, if not harder to compare the resulting data, without a very specific tool. (It is harder because some files - such as report files - may have no easy way to specify one record type from another.) Most of the tools that do the comparison for you, mask out the dates and do not compare them at all. (But doing this can miss data that could point out a hidden Year 2000 problem, such as a leap year problem.)

You must decide if it is worth the effort to age the data for testing this specific application (it is called "triage" - how important is the application to you & where would you maximize the return for the time spent). You must decide how many different system dates are appropriate to age the data to (even in my vary simple example, I had to age the data at least twice to completely test it.) You must decide if it is appropriate to age all the dates or just some of them (there are classes of dates that you would never age). You must decide if you are going to age the data by a constant amount or by s semantic constant (such as the quantity of work days).

We offer a general comparison tool which compares all date types you specify are in the file without telling the computer where any specific date is, the format of any specific date nor how to tell one record type from another.

From: "Lee"
Subject: Data Ageing: PC/Client-Server databases?

As I understand these tools (and my understanding is very poor), they:

1) insert a "shim" between the OS and the database date calls, so that the database is operating in 2000 while the hardware is still set to the correct date, 2) "age" the data in the database. Some also seem to 3) "assist" in comparing aged and non-aged output, and 4) aid (my cynical reading is hamper) test case preparation.

<Snip>

So - what advantage do these tools give over the manual method of setting the clock forward and fully testing, with a test plan. Feature 1) above seems useless in a PC environment, given the ubiquitous nature of PCs and PC servers and the ease with which they can be moved forward in time. 3) and 4) may or may not be useful (experiences please)?

That leaves 2). Why age data? Exactly what does this mean?

Are there tools genuinely useful, or yet another example of trying to apply valid mainframe methodology to the PC environment, resulting in invalid PC methodology?