Embed Size (px)
Citation preview
© 1998 SDT1
Year 2000 TestingYear 2000 Testing
Dick HoffmanApril 7, 1998
© 1998 SDT2
This document is produced by The SABRE Group, Inc., for its use and the use of AMR, AMR’ssubsidiaries and affiliates, and any non-AMR entities which they may expressly authorize to use it.
It is a working document that may be revised from time to time without notice. THE SABREGROUP, INC., DISCLAIMS ALL WARRANTIES OF ANY TYPE FOR THIS DOCUMENT,
INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR APARTICULAR PURPOSE, ACCURACY, OR COMPLETENESS. The SABRE Group, Inc., AMR,
and its subsidiaries and affiliates shall not be liable for damages of any type, including direct,consequential, or special damages, to any legal person arising out of any person’s reliance on or
use of the information in this document.
© Copyright 1998 by The SABRE Group, Inc. All rights reserved. Unlimited numbers of copiesmay be made for the internal use of the AMR companies. Any disclosure of information or
distribution of copies to non-AMR individuals or companies requires the prior permission of TheSABRE Group’s Year 2000 Project Office, which may be reached at the following addresses:
The SABRE GroupYear 2000 Project Office at 1 East Kirkwood Blvd.
MD7260 TSG, Southlake, TX 76092GroupWise mailbox “Y2000” Internet address: [email protected]
Voice mail: (817) 264-2700 Fax: (817) 264-3517
Products and company trade names, trade marks, and service marks referenced herein areowned by their respective companies, and not by the AMR companies.
© 1998 SDT3
Year 2000 ProblemYear 2000 Problem
The impact of Year 2000 on information technology is global.
The common industry practice of using two digits to representthe calendar year (i.e. 97 vs. 1997) has caused problems for anysystem and application programs which perform:
• Arithmetic operations, comparisons, sorts• Leap year calculations outside the 1900-1999 year range• Situations where a 2-digit date may be ambiguous ( i.e. is the birth date 2001 or 1901)• Hard-coded date checks (x’ 3080’ , 12/31/99, 99)
These situations must be identified and corrected. In most cases, finding the problem is much harder than fixing it.
© 1998 SDT4
What is Compliance to Year 2000What is Compliance to Year 2000
All hardware, software and microcode has userinterfaces, data data fields, processing logic andoutput that correctly recognizes, processes, andotherwise supports the Year 2000 and beyond.
The hardware, software and microcode, as well asall feature updates, upgrades and options shall sooperate whether it is used prior to, during, or afterthe calendar year 2000.
TIME is the important factor, not just date.
IT MUST WORK UP TO, ACROSS AND BEYONDTHE EVENT!
© 1998 SDT5
Year 2000 Decision CycleYear 2000 Decision Cycle
Is it Year 2000 Compliant
Yes
Done
NoWhat Needs To Be Done
Retire Repair Replace
When
Remove
When
How
When
What
© 1998 SDT6
TestingTesting
© 1998 SDT7
Future Date TestingFuture Date Testing
Problem
• Have never had to test in a true future state before Future date system dates, calendars, globals, etc. Future date databases
Solution
• Build a new test system• Simulate a future date system
© 1998 SDT8
Future Date Test SystemFuture Date Test System
Build a new system• Logically or physically separate from existing test systems• Advance to a future date state• Build or convert databases to future date , as necessary
Advantages• Closest to the “real thing”
Disadvantages• Most costly• Complicated to execute
© 1998 SDT9
Simulated Future DateSimulated Future Date
Global Date Adjustment• Global field to modify dates• Must use approved date utilities• In essence, sets a new base for PARS date Advantages• Less costly• Will expose in-line date routines
Disadvantages• Simulation of future date• Will not expose hard-coded PARS date checks• Must ensure capability never gets migrated to production
© 1998 SDT10
Testing at The Sabre GroupTesting at The Sabre Group
Using both solutions
Future Date Test System• Physically separate test system• Preferred method• All realtime systems expected to use to some extent• Discourage database conversions for future date state• Prefer to use production processes to build databases
Simulated Future Date Test System• Database may be too difficult or too large to build• Particularily effective for client/server testing• Difficult to use for passing data to offline systems
© 1998 SDT11
Y2K Test System StructureY2K Test System Structure
VPARS
BaseBase
Concat.VPARS
VPARS VPARS
UserVPARS
Request 12/28/1999 2/27/2000
© 1998 SDT12
BaseBase
• Capture from production
• Current date
• All data normally captured
© 1998 SDT13
Concatenated VPARSConcatenated VPARS
• Attached to base
• Strictly controlled
• Set to future dates
• Build future date databases and execute normal processes
© 1998 SDT14
User VPARSUser VPARS
• Controlled by individual development/test groups
• Some are strictly controlled to provide for Customer Tests
• One is set up specifically for external connectivity testing
• Future dates can also be changed here
• Can be attached to any concatenated VPARS or the base
© 1998 SDT15
SummarySummary
• Provides multiple techniques to support test situations
• Provides maximum flexibility
• Different groups can test different dates concurrently
• Tests can proceed at their own pace rather than waiting for a schedule
• Provides both controlled and totally flexible environments
© 1998 SDT16
Test System ScheduleTest System Schedule
Cross Century Test SystemCross Century Test System
Day of WeekDay of Week Clock TimeClock Time System DateSystem Date System TimeSystem Time
Monday 0800 Dec. 28, 1999 1000Monday 0800 Dec. 28, 1999 1000
Tuesday 0800 Dec. 30, 1999 2200Tuesday 0800 Dec. 30, 1999 2200
Wednesday 0800 Dec. 31, 1999 2200Wednesday 0800 Dec. 31, 1999 2200
Thursday 0800 Jan. 01, 2000 2200Thursday 0800 Jan. 01, 2000 2200
Friday 0800 Jan. 02, 2000 2200Friday 0800 Jan. 02, 2000 2200
© 1998 SDT17
Test System ScheduleTest System Schedule
Leap Year Test SystemLeap Year Test System
Day of WeekDay of Week Clock TimeClock Time System Date System TimeSystem Time
Monday 0800 Feb. 27, 2000 1000Monday 0800 Feb. 27, 2000 1000
Tuesday 0800 Feb. 28, 2000 2200Tuesday 0800 Feb. 28, 2000 2200
Wednesday 0800 Feb. 29, 2000 2200Wednesday 0800 Feb. 29, 2000 2200
Thursday 0800 Mar. 01, 2000 2200Thursday 0800 Mar. 01, 2000 2200
Friday 0800 Mar. 02, 2000 2200Friday 0800 Mar. 02, 2000 2200
© 1998 SDT18
Test ContactsTest Contacts
To discuss testing or to schedule a test with The SabreTo discuss testing or to schedule a test with The Sabre
Group, contact:Group, contact:
Velma BoodtVelma Boodt
Phone: (918) 828-6221Phone: (918) 828-6221
E-Mail: [email protected]: [email protected]
Dick HoffmanDick Hoffman
Phone: (817) 264-3759Phone: (817) 264-3759
E-Mail: [email protected]: [email protected]
© 1998 SDT19
InterfacesInterfaces
© 1998 SDT20
InterfacesInterfaces
• Most difficult part of the project
• Definition• Internal versus External• Ownership and responsibility for testing• Dependency
• Greatest potential for failure
© 1998 SDT21
Interface DefinitionInterface Definition
What is my sub-system’s domain?What is my sub-system’s domain?
Sub-systemComponents
© 1998 SDT22
Interface - InternalInterface - Internal
What is my company’s domain?What is my company’s domain?
Who do I interface with in that domain?Who do I interface with in that domain?
RT C/S OffLine
RT C/S RT
Company XYZ
© 1998 SDT23
Interface - ExternalInterface - External
Who do I interface with outside of my company’s domain?Who do I interface with outside of my company’s domain?
Company XYZCo.ABC Co.
DEF
Co. JKL Co. MNO
© 1998 SDT24
Interface IssuesInterface Issues
• Identifying all interfaces, internal and external (Inventory)• Types of interfaces - Sub-system, record (DSECT), data, tape, paper• Ownership of the interface• Responsibility for testing the interface• Contacts - names, phone numbers, addresses• Scheduling tests• Tracking what has been tested and what hasn’t been tested• Physical test versus Interface Specification Test
© 1998 SDT25
QuestionsQuestions
