Y2K testing

[Deskin, Bob]

There are two main aspects to year 200 testing (plus other small ones). One
is to ensure that the interface with the system is correct. For dates, this
would take the form of using SYSDATE. And the other is to ensure that the
data processing portion is correct independent of the system date. For
example, within PowerHouse we test that the function SYSDATE is correctly
returned on a variety of system dates. However, the rest of the date
functions (DAYS, DATE, etc.) and date functionality (formatting, editing,
etc.) are independent of the actual machine date so we don't have to test
them on a variety of system dates. However, we do have to test those
functions and functionality on a variety of date data including data before
and after 1999.

The issue is that most application systems intermix both SYSDATE and other
date functions and functionality. Once you're testing SYSDATE, you really
need to test the rest of the logic at the same time. For example, let's say
you had a QUIZ report that selected based on comparing SYSDATE to an invoice
date. Obviously if you run this on different days (i.e. changing the machine
date) you'll get different results. However, if your data stops at Jan 10,
1999 (for example) and you test by setting the machine after Jan 10, 1999,
your test results won't change reagrdless of the system date. In order to
properly test this selection, you need data that runs into the 2000s. And it
should at least go past Feb 29, 2000.

The idea is to ensure that everything has been caught. The degree of testing
will depend on your applications. If you know the application very well -
like you wrote it or have maintained it for years - then you'll know what to
watch for. But if you have to test an application that you know very little
about, the testing should be constructed to catch anything that the
programmers missed. The biggest concern in this area is date items that are
stored as numerics. These may be very difficult to find, but will cause
problems. A typical example is the fiscal year or a year-week.

Bob Deskin              
Senior Product Advisor  bob.deskin@cognos.com
Cognos Inc.             (613) 738-1338 ext 4205 FAX: (613) 228-3149
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA


> ----------
> From: 	Richard Kessler[SMTP:71051.1106@compuserve.com]
> Sent: 	Wednesday, December 23, 1998 10:15 AM
> To: 	All
> Subject: 	RE: Y2K testing
> 
> Wanda, 
> Am curious what sort of problems you could have that would be unexpected
> !?!
> While I agree with everyone here that actually having a system where the
> date can be pushed ahead to past 2000 is a very good idea,  I see that as
> testing the compatability of the system hardware and operating system
> with Y2K, NOT testing the PowerHouse code suitability. 
> 
> Am also questioning Bob Deskins earlier statement in the same manner in
> that :
> I should think that if you rework your powerhouse code (presumably under
> 8.1x)
> and unload and reload the data with addcentury so that the 8 digit dates
> contain 8 digits (19981222) then it does not matter for testing - at least
> the powerhouse coding and powerhouse interface with the operating
> system aspect - whether the century used is 19 or 20.
> 
> Am I missing something by thinking that the powerhouse coding Y2k
> problem is separate from the hardware/operating system problem, or just 
> overreacting to everyone's good idea to also test (the system) by
> pushing the date ahead ??
> 
> Richard Kessler
> 71051.1106@compusereve.com
> 
> Message text written by "Ravenscroft, Wanda L"
> >
> If it's something your company can do, I would do it.  I work on a VMS
> system and we have a development system set up whereby we can change the
> date to a year 2000 date and it has been of great value to us.  We've
> found
> and resolved alot of problems that we had not expected we would have.
> 
> Wanda Ravenscroft
> Energizer
> VMS 6.1, Powerhouse 7.10F1
> <
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.