standard test approach · web viewoverview 8 milestone 1 - planning phase 8 milestone 2 -...

Testing StrategyPDB Uptime System Testing

October 4, 2004

© 2004, Harrah’s Entertainment, Inc. Confidential

PDB Uptime System Testing Print Date: October 1, 2004

Document Signoff:

Project ManagerProgram ManagerEngineering LeadTest ManagerTest LeadLead Data Analyst________________________________________

Document Information:Revision: 5.0Date Revised: 30 Sept 2004Filename: document.doc

- 2 -



Revision HistoryName Date Comments

Bob Livingston 30 Sept 04 First Draft

People Responsible for AppTest Lead: Bob LivingstonTester: Bob LivingstonDeveloper: StaffDeveloper Lead: StaffProject Manager: Linda Stacey

Other People Associated with AppSupport Analyst: Staff

Brief Application Description

PDB Uptime AIX and Informix Upgrades

- 3 -



Table of Contents

INTRODUCTION........................................................................................................................................................ 6

DOCUMENT SUMMARY............................................................................................................................................ 6

GOALS AND OBJECTIVES....................................................................................................................................... 6BACKGROUND........................................................................................................................................................... 6PROJECT VISION AND GOALS...................................................................................................................................... 6PROJECT QUALITY GOALS.......................................................................................................................................... 7TESTING GOALS........................................................................................................................................................ 7

SCOPE....................................................................................................................................................................... 8AREAS TESTED (TENTATIVE AS OF 30 SEPT 04)...........................................................................................................8

Sample Test Scripts (tentative – and see examples from an older system test in the icon below)..........................8Initial List of Test Scenarios (from John McGowan – these will be tested first in the order below)..........................8

OTHER AREAS NOT TESTED....................................................................................................................................... 8FEATURES/FUNCTIONALITY TESTED............................................................................................................................. 8FEATURES NOT TESTED............................................................................................................................................. 8TEST DIRECTOR PARTS AND “TEST TREE”...................................................................................................................8

Requirements....................................................................................................................................................... 8Test Plan............................................................................................................................................................. 8Test Lab.............................................................................................................................................................. 8Defects................................................................................................................................................................ 8Test Tree (tentative)............................................................................................................................................. 8

TEST ENVIRONMENT.................................................................................................................................................. 8Hardware............................................................................................................................................................. 8Software.............................................................................................................................................................. 8Operating Systems.............................................................................................................................................. 8

TEST SCHEDULE...................................................................................................................................................... 8MILESTONE LIST........................................................................................................................................................ 8ASSUMPTIONS........................................................................................................................................................... 8RISKS....................................................................................................................................................................... 8

TEST DELIVERABLES.............................................................................................................................................. 8DELIVERABLES MATRIX............................................................................................................................................... 8DOCUMENTS............................................................................................................................................................. 8

Test Plan (see Appendix B for a copy of it as it exists now which is not complete nor finalized).............................8Test Schedule...................................................................................................................................................... 8Test Specifications............................................................................................................................................... 8

TEST CASE/BUG WRITE-UPS...................................................................................................................................... 8Test Director Test Cases...................................................................................................................................... 8Test Director Coverage Reports........................................................................................................................... 8Test Director Bugs and Regression Results..........................................................................................................8Test Director Analyzer Bug Reports...................................................................................................................... 8

REPORTS.................................................................................................................................................................. 8Weekly Status Reports......................................................................................................................................... 8Phase Completion Reports................................................................................................................................... 8Test Final Report - Sign-Off.................................................................................................................................. 8CD Archive.......................................................................................................................................................... 8

RESPONSIBILITY MATRIX............................................................................................................................................. 8

TEST METHODOLOGY............................................................................................................................................. 8TEST STAGES........................................................................................................................................................... 8

Overview.............................................................................................................................................................. 8

- 4 -



Milestone 1 - Planning Phase............................................................................................................................... 8Milestone 2 - Upgrade/PDB Build Phase...............................................................................................................8Milestone 2a - Usability Testing (Build Testing).....................................................................................................8

Milestone 3a - Unit Testing (Multiple SPFs).......................................................................................................8Milestone 3b - Regression (System) Testing.........................................................................................................8Milestone 4 - Stabilization Phase.......................................................................................................................... 8Milestone 4a – Release into Production................................................................................................................8Milestone 4c - Post Release................................................................................................................................. 8

TEST LEVELS............................................................................................................................................................ 8Build Tests........................................................................................................................................................... 8

Level 1 - Build Acceptance Tests....................................................................................................................................... 8Level 2 - Smoke Tests...................................................................................................................................................... 8Level 3 - Bug Regression Testing...................................................................................................................................... 8

Milestone Tests.................................................................................................................................................... 8Level 4 - Critical Path Tests............................................................................................................................................... 8

Release Tests...................................................................................................................................................... 8Level 5 - Standard Tests................................................................................................................................................... 8Level 5 - Suggested Tests................................................................................................................................................. 8

BUG REGRESSION..................................................................................................................................................... 8BUG TRIAGE............................................................................................................................................................. 8SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS.............................................................................................8TEST COMPLETENESS................................................................................................................................................ 8

Standard Conditions:............................................................................................................................................ 8Bug Reporting & Triage Conditions:......................................................................................................................8

CRITERIA FOR ACCEPTANCE INTO TESTING........................................................................................................8

TEST DIRECTOR (TEST CASE/BUG/ISSUE MANAGER) AND TEST DIRECTOR DATABASE STANDARDS............................................................................................................................................................. 8

TEST CASES............................................................................................................................................................. 8BUG DOCUMENTATION............................................................................................................................................... 8BUG SEVERITY AND PRIORITY DEFINITION.................................................................................................................... 8

Severity List......................................................................................................................................................... 8Priority List........................................................................................................................................................... 8

BUG REPORTING....................................................................................................................................................... 8BUG ENTRY FIELDS................................................................................................................................................... 8

Bug Type............................................................................................................................................................. 8Assigned To......................................................................................................................................................... 8Project................................................................................................................................................................. 8Status.................................................................................................................................................................. 8Source................................................................................................................................................................. 8Priority................................................................................................................................................................. 8Severity............................................................................................................................................................... 8Code 1................................................................................................................................................................. 8

APPENDIX A.............................................................................................................................................................. 8LIST OF UNIT TESTS (SCRIPTS) ON NEWDEV.................................................................................................................8

APPENDIX B (EXAMPLES ONLY – NOT FINALIZED, ANY INFO IN THIS SECTION)..............................................8

TEST PLAN (DRAFT – NOT COMPLETE; NEEDS TO BE DONE IN MS PROJECT).................................................8Known issues between AIX 4.3.3 and 5.2 (installation and migration related topics—these items below need to be include in the final Test Plan)................................................................................................................................ 8

- 5 -



IntroductionThis document describes the approach and methodologies used by the testing group to plan, organize and manage the testing of the PDB Uptime system upgrade to AIX 5.2. It does not describe implementation details of test cases or technical details of how the PDB features should work. See the Test Scenarios document for that information or for reference to where it is located (or see Test Director).

Document SummaryIn this test plan, the following areas are included:

Goals and objectives that describe what is most important about the project and the tests needed for it Scope describes what will be and what will not be tested under this plan The test schedule is presented, based on stated assumptions, with principal risks and contingencies The test deliverables section indicates what deliverables testing has to produce and contains a matrix that should

be extracted and routinely updated as the items to be produced are generated. The section also contains a sub-section on other development team members’ responsibilities—extract this matrix and use it also to guide who does what

Test methodology is a progression of stages and quality levels to be expected as the project matures, as well as the typical cycle of testing

Criteria for acceptance into testing defines what Testing’s expectations are to accept a build for testing Test Director and Test Director database standards are listed so that developers, project managers, and others

understand the basic standards of how and where we track test cases and bugs. Parties external to testing will use Test Director and will read the Test Director reports.

Goals and ObjectivesThis section defines the goals and objectives for the project, for the quality of the project, and for the testing team members.

BackgroundThe PDB Uptime project is a client server application that supports nationwide (brandwide) guest recognition and offer processing.

It was written originally in 1993.

Project Vision and Goals

All layers of PDB as defined in the current Technical Architecture Manual work as before when AIX is upgraded from 4.3.3 to 5.2 and that:

o All database services (data files from remote systems that are submitted to the batch processing service - data that is extracted from the central PDB and shipped to parallel servers at the properties – and, extracted data that is used to create databases on the parallel servers)

o Data broadcast facilitieso Database primitiveso Caching services

. . .are working correctly for PDB execution Top End correctly:

- 6 -



o Determines the service needed from the data extractedo Creates an appropriate response to the requesto Calls PAMS to build a response buffer containing all response datao Builds the response buffer into the global buffer ‘outgoing’o Exits with all resources in an ‘as found’ conditiono Returns a less then zero return code to indicate erroro Return a greater then zero return code to indicate no error, AND no responseo Returns a zero as its normal exit code

All SPFs work correctly All user functionality works correctly All gateways work correctly (LU.6.2 nodes) All tracing done via the Fred Fish Debugger works correctly All related systems such as Offers and Suspense and sub-systems such as MWB, Security Maintenance,

Reporting, etc. work correctly NEW features (if any) work correctly or new performance benchmarks are met such as XXXXXXXXXXX

Project Quality GoalsQuality expectations include:

Reliability and proper functioning as specified and expected Robustness and acceptable response to unusual inputs, loads, and conditions Timely and expected delivery schedule Efficiency of use by the frequent users System is easy, attractive and helpful for the less frequent users

Testing GoalsTesting goals include:

Identify and publish the scope and substance of the testing effort (test case coverage report) Identify and publish risks to the successful completion of the project Verify functional correctness (critical path must work in PDB without flaws) Report on the status of the project regarding the tests and measures (weekly status reports to be

produced/distributed) Confirm consistency throughout the implementation of the PDB system when running on an upgraded AIX version

(5.2) Confirm consistency with standards in other applications (if required) Test PDB robustness and stability after the AIX upgrade Measure performance ‘hot spots’ (locations or features that are problem areas) and make sure all are working to

an acceptable level

- 7 -



ScopeThis section defines the scope of the testing. It identifies what items (files, functions, modules, interfaces, communications, etc.) and what features (user and system) will be tested.

Areas Tested (tentative as of 30 Sept 04)

Test # Area NameYes 1 Installation of AIX and/or Informix upgrades (note that no decision has been made to upgrade

Informix at the same time as AIX; however, this same test strategy, scope and plan may be re-used to test an Informix upgrade at the appropriate time with some additional test cases added to test Informix in respect to how the existing Informix database instances should work when used on an upgraded version)

Yes 2 User interface (may not test this other than to do some WINet® extracts on guests, offers, etc.) – the extent of this testing is not yet decided

Yes 3 Compilers – all scripts and executables will be tested to ensure proper operation on an upgraded version of AIX from 4.3.3 to 5.2 – any old scripts not used will be removed

Yes 4 Environment (stability of to be verified by error tracking, performance [speed, etc.], and any indications of problems on the AIX platform itself with Top End, queues, etc.)

Yes 5 Error Handling (how resolved, manually or by the system itself)Yes 6 Performance (speed)Yes 7 Stress/load (high volumes, erratic volumes, large message types, message “pools” by

size/volume, time of day, etc.)Yes 8 Utilities (Fred Fish Debugger and any monitoring tools that may be installed/added) and compilerYes 9 User Scenarios (as with #2 above, situations that simulate various ways users are working on the

WINet® system or how PDB is working in a “real world” set up or simulation)Yes 10 Harrah’s or third party application program interface (API), i.e. Code1, etc. that need validation

against PDB on the new AIX releaseYes 11 Expected input and output of PAMS messagesYes 12 All external files that are used as input as well as any files created as outputYes 13 All database tables, SQL, and/or database primitives usedYes 14 All SPFs as related to #’s 15, 16, and 17 belowYes 15 All on-line processingYes 16 All batch processingYes 17 All report processing

18 See table below for further details on 15, 16, and 17 and related SPF testing—all SPF areas need related test scripts/expected results

Yes 19 Security maintenance processing (limited testing here)202122

#18 (further details)

SPF Directory Description NotesORF415 reports 7 day offer redemption reportOFR750 online Add individual to RG (related group)GRF410 reports Address change audit logGRF407 reports Address standardization error log by brandGRF405 reports Address standardization error log by property

Address/Account Standardization and ConsistencyAll combines for CMS/LMS/EMS

- 8 -



Batch Movement to MWBGUX300 batch Calculates guest reward creditsDDP101 batch Calls stored procedures to perform theOFB202 batch Cashless black-out date functionalityOFR551 online Cashless blackout date maintenanceGUX270 batch CMS only combinesOFR550 online Collateral associate maintenanceOFR500 online Collateral maintenance

Collection and storage of local play informationCollection and storage of point informationCommunications to CMS/LMS/EMS through SNA and PDB through TCP/IPComp redemptionsConnectivity

GEX260 batch Creates the actual extracts for CMSCreation of mail files & export of same to AS/400

PRF455 reports Cross property visitation reportPRF480 reports Cross property visitation w/ Dom prop

Daily Play informationDB PrimitivesDB PrimitivesDB/SQLDB/SQLDefinition, tracking and reporting on promotional offers sent to customers

OFR820 online Deletes group of guests from rgsOFRBAT batch Description ?PFSSTAT ? Description ?PUX410 batch Description ?PUX420 batch Description ?PUX430 batch Description ?PUX440 batch Description ?PUX450 batch Description ?PUX515 batch Description ?PUX520 batch Description ?OFR903 batch Does validation on potential var_coup_amt records

End of day processingPUX158 batch Event trip processingERF415 reports Event/ hotel/ gaming activity for event

EventsEvents offers

GEX255 batch Extracts guests for NCOA processingPRF460 reports File transmission report for Ops

Food/Retail Comp redemptionFormatting and communication of messages between systems

GUX270B batch Full WINet® combinesGEX259 batch Generates the lists of ids for guest sync

Guest Add/Change/DeleteGEX258 batch Guest bank info to CMSGSX545 online Guest bank information called by gsx510 thru

tp_dialogGUX220 batch Guest bank postingCUX221 batch Guest comp processing/postingGSX540 online Guest credit information

- 9 -



GSX640 online Guest cross-reference informationCUX201 batch Guest game processing/postingGSX555 online Guest hotel informationGSX565 online Guest interest informationGUX250 batch Guest interest postingGSX585 online Guest links informationGUX210 batch Guest master postingPUX153 batch Guest master processingGUX240 batch Guest message postingGSX535 online Guest message selectGSX550 online Guest personal informationGSX510 online Guest select calls gsx545 thru

tp_dialogGSX521 online Guest trip detail summary - for PCS ?CUX212 batch Guest trip processing/postingGSX515 online Guest trip summary selectGSX520 online Guest trip summary selectHRF420 reports Hotel group summary information

Hotel offersHUX210 batch Hotel stay extract postingPUX159 batch Hotel stay extract processing

Hotel staysGSX530 online Information for the comp detail screenGSX525 online Information for the Play Detail ScreenOFB300 batch Initiates messages to start mail file processingOFR951 online Internet effective date

KioskOFR901 online List transfer program

Load balancingOFR902 batch Loads guests into the paradb tableOFR904 batch Loads guests into the paradb table and the recp group

tableCRF475 reports Looks like an event report

Mail files are transferred to vendor for actual offer distribution to customer

OFR200 online Mail generation/regen messageGUX581 online Maintain some guest preferencesGUX582 online Maintain the other guest preferencesOFR450 online Maintenance for offer cost tableGUX580 online Manual guest add/update from guest master screenGUX570 online Manual tier updates

Merge/PurgeGUX260 batch Merge/Purge processing

MessagesMessages, status, etc.MWB (see separate line below for tests here)National Change of Address (NCOA)NCOANightly Process

ORF405 reports Offer assignment exceptionsOffer definition and assignment of Ids

OFB200 batch Offer mail file generationOffer Management

OFR100 online Offer modification/creationORF455 reports Offer redemption report

- 10 -



Offer reservations/redemptionOFB500 batch Offer retraction processORF410 reports Offer summary estimate report

Offers reservations/redemption GRF415 reports Online accounts combine audit logGUX285 online Online susp merge purgeGUX590 online Online WINet® Merge/PurgeOFR900 online Paradb list maintenance

PDB Trip Combine PMX900 online PF4 lookup functionalityDDP100 online Places message for DDP101 on Queue

Player Credit InformationPlayer MessagesPlayer PreferencesPlayer Rating & Comps

OFR150 online Populates the offer list window in Win clientPRF470 reports Possible casino combine report

Posting of hotel offersPUX160 batch Posts 9 different input files (event & hotel)EUX210 batch Posts event detail recordsEUX211 batch Posts event ticket block recordsCUX230 batch Posts guest currency informationGUX211 batch Processes guest master suspenseOFB400 batch Processes offer redemptions from extract filesPUX147 batch Processes the event date/time filePUX145 batch Processes the event master filePUX149 batch Processes the event ticket block filePUX150 batch Processes the guest bank filePUX155 batch Processes the guest currency extractPUX154 batch Processes the guest interest filePUX152 batch Processes the guest message filePUX146 batch Processes the hotel group code filePUX401 batch Processes Trip, Shortened Trips, Deleted trips, comp and

rating recordsPRX515 online Provides list of available print queuesPRX550 online Provides list of event reportsPRX560 online Provides list of groups and group types available for

printingPRX520 online Provides list of re-printable reportsPRX510 online Provides listing of available reportsPUX570 online Provides the details for the Windows suspense

processing applicationPUX400 batch Reads from pdb_trip_candidate and creates appropriate

TE/PAMS messageReceipt of offer control files from client workstations

OFR650 online Recipient group association maintenanceOFR600 online Recipient group maintenanceOFR810 online Recipient group maintenanceOFR401 online Redemption or invalidation of offerPRF412 reports Report of susp_comp tablePRF413 reports Report of susp_currPRF415 reports Report of susp_eventPRF417 reports Report of susp_event_date_timePRF419 reports Report of susp_event_tripPRF418 reports Report of susp_evt_tktblk

- 11 -



PRF420 reports Report of susp_groupPRF400 reports Report of susp_guest tablePRF421 reports Report of susp_hotelPRF422 reports Report of susp_intrPRF423 reports Report of susp_messagePRF410 reports Report of susp_trip tablePRF424 reports Report of susp_w2gPRF411 reports Report of trans summary susp _tripPRF416 reports Report of transaction summary susp_event_tripPRX530 online Report submit modulePRX525 online Reprints reports w/o regenerationGSX630 online Repsonds to a sync request to supply updates for

cashless couponsORF465 reports Reserve/redeem offer reportOFR400 online Reserves/redeems/voids/unredeems couponsOFR402 online Retract offer/delete collateral/remove individual/ remove

collateralGSX610 online Retrieves cashless coupons for guests on card inOFR050 online Retrieves offer detail informationOFR851 online Retrieves offer informationOFR950 online Returns collateral/coupon info for offerCUX245 batch Reward credit balance processing/postingOFR700 online RG associate collateralERF420 reports Room event comparison reportERF410 reports Room event summary SDSOFB201 batch Secure offer mail file transfersOFR850 online Selects offer sent/redeemed information for a guestBTCHSCH

batch Sets up the RTQ workflow for batch processing for the different files

GSX620 online Something to do with cashlessHRF465 reports Source group summary reportHRF475 reports Source group summary totals report SQL SQLOFR350 online Supports coupon functionsOFR351 online Supports vendor functionsCUX250 batch Tierscore processing/postingPUX100 batch Traffic cop for daily batch file processingPUX515B batch Transitions properties from 3 to 4PUX400B batch Transitions properties from 5 to 6 Trip HistoriesPUX101 batch Updates the transmit log table with correct status for

batch files.PMX910 batch Used to execute a "system" call from within Top EndGUX230 batch W2g postingPUX151 batch W2-g processingCRF470 reports Wholesale group summary reportGUX280 batch Y-susp combine processing

#18 (further details – different view)

Type Of Processing

System Name Test... (On Component) Test... (On Sub-Component)

On-line PDB All combines for CMS/LMS/EMS Player Rating & Comps

WINET® available WINET® combine

- 12 -



Player Preferences Trip Histories Player Messages Player Credit Information Offer Management Address/Account Standardization

and Consistency

WINET® down WINET® extract

processing WINET® synch

processing

MWB (see separate line below for tests here)

Data summarized differently here (see separate line below for tests here)

On-line CMS Collection and storage of point information

Collection and storage of local play information

CMS combine Comp profiling -

(control accounts) Point transactions -

(control accounts) Auto-activation -

(control accounts)

On-line Kiosk Point balances, redemptions

On-line SDS Customer point balances SDS – switch sides

SDS refresh

On-line LMS Hotel offers Posting of hotel offers Offers reservations/redemption

On-line EMS Events offers Offer reservations/redemption

On-line POS Food/Retail Comp redemption

PDB ComponentsOn-line Top End Messages

Connectivity Load balancing

ON-LINE Top End Gateways Communications to CMS/LMS/EMS through SNA and PDB through TCP/IP

Messages, status, etc.On-line Primitives DB Primitives

DB/SQL SQL

On-line DB Primitives Database lookups for multiple uses

On-line DB/SQL Complex queries written for a specific usage

On-line SQL Basic SQL queries written for a specific usage

- 13 -



On-line PAMS Formatting and communication of messages between systems

Batch PDB BatchApplications

End of day processing Guest Add/Change/Delete Daily Play information Comp redemptions Hotel stays Events PDB Trip Combine Batch Movement to MWB National Change of Address

(NCOA) Nightly Process

Batch NCOA Outside mailing list updates processing

Updates Merge/Purge

candidate table

Batch Merge/Purge Consolidation of duplicate guest information into one guest record

Check adds/changes

Shrinking of candidate table and qualifying of pairs.

On-line combine to combine 2 guest records manually

Purge Process

Offers ComponentsOn-line Offers Definition, tracking and reporting

on promotional offers sent to customers

Receipt of offer control files from client workstations

Offer definition and assignment of Ids

Creation of mail files & export of same to AS/400

Mail files are transferred to vendor for actual offer distribution to customer

Offer - un-redemption

Offer display Offer mail file Offer mail file –

volume tests Offer re-mail Offers – pc client PTC offer

redemption - (control accounts)

Coupon (PTC) redemption

Coupon (regular) redemption

Coupon redemption

Coupon redemption - (re-test)

Coupon refresh Coupon request Speed offer

- 14 -



redemption Pre-printed

coupons Redemption

synchronization Card-in/coupon

request - volume test

Property participation

Vendor file voidSuspense ComponentsOn-line Process WINet® Suspended Records

Process CMS Suspended RecordsGuest Merge Suspense Update

Event

Event Ticket Block

Event Date Time

Event Trip

Hotel Group

Hotel

Bank

Casino Comp

Casino CurrencyCasino GameCasino GuestCasino InterestCasino MessageCasino TripW2G

MWB ComponentsOn-line MWB batch load Movement of data between PDB and MWB

Detail Layer Summarization

On-line Cognos Impromptu Query Tool to access data Lists for analysis and offers

On-line Catalog Logical views of the data

On-line ImpromptuClient

Point/Click interface Submission of queries to Impromptu Request Server

On-line Impromptu request server

That each PC is connected to one “instance” of Request Server

WINet® Reporting ComponentsOn-line Hotel Group Summary

Offer Assign Exceptions Address Changes Audit LogShow Room Events CompareShow Room Events Week to WeekWholesale Group SummaryOthers ????

Security Maintenance ComponentsOn-line Provides ability to Create or Delete a User Profile

Provides a list of screens a User Profile currently can access

- 15 -



Allows screen access additions or deletions for a specific User Profile

Allows a current user file access to be copied for a different user profile

Requires setup of a default printer outq for each User Profile

Guest Recognition ComponentsOn-line Retrieve guest by Winner® ID

Retrieval guest by full nameRetrieval guest by partial name.Retrieval guest by phone numberRetrieval guest by social security num.Retrieval guest by credit card num.Retrieval guest by drivers license num.Retrieval guest trip summaryRetrieval guest trip detail Retrieval guest messagesRetrieval guest credit informationRetrieval guest bank informationRetrieval guest personal informationRetrieval guest interest inquiry screenRetrieval guest maintenance screenRetrieval guest address listRetrieval guest offer sent listRetrieval guest interest maint. ScreenRetrieval guest hotelRetrieval guest linksAS/400 user screensInternet display

FOH//WINet® - PDB//Online SPs//wtemsg

Sample Test Scripts (tentative – and see examples from an older system test in the icon below)

C:\BLivingston_9_2004_A\New test strategy docs 23 9 04\System Test.xls

Case Description (all below related to Guest Maintenance activities)

See System Test.xls (link above on icon)

1 Add a guest GUX583|CDTPA|USERSTURMAN|ACCT|CMSA|PRID|GSTI|RELII||gname|FNAM1|LNAM1|PMCD100|ADTPH|ACCT0010490000001|MLFLY|PRCDLAS|DTOB29812||gpersonl|GNDRM|SSNU123456789|DLNM12345678|DLSCTN|MARIS|ANNV37482|FRNMHARRAHS|OCCUPROGRAMMER|JOBTSR. PA|NYRS2|FROFN|SICD1||addrupd|ADTPH|ADD13031 MORIAH TRAILS|ADD2|APTN105|CITYMEMPHIS|STCDTN|PZIP38115|COCDUS|MLCDG||addrupd|ADTPB|ADD11023 CHERRY ROAD|ADD2|APTN|CITYMEMPHIS|STCDTN|PZIP38117|COCDUS|MLCDG||phoneupd|HTLN9011234567|

- 16 -

See full details of list of cases below by clicking on the icon to the left



BPHN9017654321||2 Second name add with 19x ID already

assigned, primary account does not have second name

3 Second name add with existing, non-19x ID already assigned, primary account does not have second name

4 Second name add without ID already assigned, primary account does not have second name

5 Second name add with 19x ID already assigned, primary account has second name

6 Second name add with existing, non-19x ID already assigned, primary account has second name

7 Second name add without ID already assigned, primary account has second name

8 Invalid gender9 Invalid preferred address type10 Invalid mail flag11 Invalid anniversary date12 Invalid marital status13 Invalid social security number14 Invalid driver's license15 Invalid driver's license state16 Invalid date of birth17 Interactive Reliability with invalid Property

Mail Code, i.e. 100/200/300 that isn't in mail_code_standard

18 Interactive Reliability with vaild non-300 series Property Mail Code

19 Interactive Reliability with valid 300 series Property Mail Code

20 Batch Reliability with valid 200 series Property Mail Code

21 Batch Reliability with Override Property Mail Code and address that won't standardize

22 Batch Reliability with Override Property Mail Code and address that will standardize

23 Batch Reliability with 300 series Property Mail Code and address that will standardize

24 Activate at a property where the guest has never had activity

25 Activate at a property where the guest has had activity under a different ID from the ID given to activate

26 Activate a previously activated ID against an ID that is not the ID it was previously activated against

27 Add with no mail code, no address preference, and empty home address

28 Add with no mail code, no address preference, and empty business address

29 PN add with null ACCT in gname30 PN add with null PRCD in gname31 PN add with null FNAM in gname

- 17 -

Click on Excel icon above for details on all cases below that have gray cells beside them



32 PN add with null LNAM in gname33 SN add with null PRID in GUX58334 SN add with null GSTI in GUX58335 Activate-Add with null FNAM in gname36 Activate-Add with null LNAM in gname37 Activate with null ACCT in GUX58338 Activate with null CMSA in GUX58339 Activate with WINet® ID that has never been

added40 Unrecognized code type41 Activate with null PRCD in gname42 Second name add when primary name

account doesn't exist43 USA address that standardizes44 USA address that won't standardize45 CAN address that standardizes46 CAN address that won't standardize47 Multiple addresses - all standardize48 Multiple addresses - some standardize49 Multiple addresses - none standardize50 Foreign address51 Address with only some of the required fields52 Address with no fields53 Bad message54 Unrecognized function

Initial List of Test Scenarios (from John McGowan – these will be tested first in the order below)

Case Descriptions Step 1 Step 2 Step 3 Step 41 Send extracts to set-up

information in test5 environment and process the synch

Need list & names of all extracts

2 Compile AIX service provider programs and see if they go active

Compiling will have to be done on all between AIX 4.3.3 and 5.2 (see Appendix B for list of steps to do)

3 Execute AIX version programs 4 Test startup and shutdown of all

SP's and queues

5 Update destination tables 6 Reset FLUID 7 Migrate monitoring scripts and

tools

8 Migrate ssc, sh and related scripts 9 Plan test for MWB - document

success criteria

10 Must be able to process extract files received from test run

11 Setup MWB environment to run

- 18 -



MWB dailies to confirm proper extracts

12 Execute full production look alike test run w/ 1 week’s worth of volume - including extracts to MWB (suggest 3 properties - ATL, NKC AND LAS)

13 Kick off dom prop, merge/purge and NCOA processes

14 Run interactive lookups during posting

15 Perform some offers work during this posting

16 Make sure all service providers are up and running

Set-up hotel/ event reservations (guest information only) and new casino account - run the reset_db (“some date”) stored procedure to clear the database

“Some date” should be before the box date

17 Test hotel checkout, event completion information, and casino transactions (new accounts, ratings, messages, etc

Make sure all 33? service providers are up and running

Checkpoint 2 should have just been run

Nothing else should have been posted to the database since the last use of the stored procedure reset_db

CHECKPOINTS ARE NOT DEFINED IN THIS TABLE

18 Test casino transactions, for example:

Updates, deletions, markers, etc.

Offer creation - make sure all 33? service providers are up and running

19 Retrieve a guest using a WINet® ID number

In the guest master screen, type the WINet® ID and press the enter key

20 Retrieve guest messages In the guest master screen, in the guest ID field type input below

Press the enter key

When the guest master screen appears, place cursor in the next field at lower left hand corner of screen

21 Retrieve guest credit information In the guest master screen, the guest ID field type input below

Press the enter key


22 Retrieve guest bank information In the guest master

Press the enter key

When the guest master screen

- 19 -



screen, in the guest ID field type input below

appears, place cursor in the next field at lower left hand corner of screen

23 Retrieve guest personal information

In the guest master screen, in the guest ID field type input below

Press the enter key


24 Retrieve guest interest inquiry In the guest master screen, in the guest ID field type input below

Press the enter key

When the guest master screen appears, place cursor on the next field at lower left hand corner of screen

25 Retrieve guest maintenance In the guest master screen, in the guest ID field type input below

Press the enter key


26 Retrieve guest address list In the guest master screen, in the guest ID field type input below

Press the enter key


27 Retrieve guest offer sent In the guest master screen, in the guest ID field type input below

Press the enter key


28 Retrieve guest interest maintenance


Press the enter key


29 Retrieve guest hotel In the guest master screen, in the guest ID field type input below

Press the enter key


30 Retrieve a guest using full name of guest

In the guest master screen, type the last name in the last name field and the first name in the first name field

Press the enter key

31 Retrieve guest links, flip between the links and retrieve the

In the guest master

Press the enter key

When the guest master screen

When the guest master screen appears, place

- 20 -



secondary account information screen, in the guest ID field type input below

appears, place cursor in the next field at lower left hand corner of screen

cursor in the next field at lower left hand corner of screen

32 Retrieve a guest using a partial name

In the guest master screen, in the last name field type first input and in the first name field, type the second input

Press the enter key

33 Retrieve a guest using a phone number


In ID type field, type 3

Press the enter key

34 Retrieve a guest using a social security number



Press the enter key

35 Retrieve a guest using a credit card number



Press the enter key

36 Retrieve a guest using a drivers license number



Press the enter key

37 Retrieve a guest trip summary information


Press the enter key


38 Retrieve a guest trip detail information


Press the enter key


39 Create a brand offer (#1) without cashless coupons for a list of guests for valid testing date range

40 Create a brand offer (#2) with fixed cashless coupon amounts for a list of guests

41 Add collateral to brand offer #2 with variable coupon amounts and black-out dates

- 21 -



42 Add collateral to brand offer #2 valid only at one property with variable cashless coupon amounts and with black-out dates

43 Offers display on WINet® screens appropriately

44 Offers display on Internet appropriately

45 Send offer mail file to vendor Create tape version and e-mail version

46 Create an offer with coupons for a large list of guests

47 Print the hotel group summary report

48 Print the offer assign exceptions report

49 Print the address changes audit log report

50 Print the show room events compare report

51 Print the show room events week to week report

52 Print the wholesale group summary report

53 Create pre-printed coupon file for each valid denomination and valid testing date range

54 Create pre-printed coupon file for each denomination and not valid for testing date range

55 Redeem a non-cashless coupon using the PDB offers screen – property does not participate in MPCI (sypcn flag set to ‘n’)

56 Redeem an offer with a PTC using the offers screen – property does not participate in MPCI (sypcn flag set to ‘n’)

57 1st card-in and rating for a guest with an offer without cashless coupons – property participates (sypcn flag set to ‘y’)

58 1st card-in and rating for guest with cashless coupons for valid dates

59 1st card-in and rating for guest with cashless coupons for valid and invalid dates

60 Card-in and rating for guest with cashless coupon

61 Run nightly batch jobs, send winet®® extracts

62 Generate volume card-in/coupon requests

63 Attempt to modify cashless coupon amounts that have already

- 22 -



been mailed64 Attempt to modify black-out dates

for an offer that has already been mailed

65 Retract an offer with cashless coupons that has been “mailed”

66 Add accounts to brand offers with cashless coupons that has already been “mailed” and re-mail

67 Redeem offer with ptc for guest 68 Un-redeem a non-cashless

coupon for a guest

69 Card-in and insert valid pre-printed coupon

70 Card-in and attempt to redeem a cashless coupon that was previously redeemed at the slot machine

71 Card-in and insert valid offer cashless coupon

72 Insert valid offer cashless coupon without a player card

73 Card-in with an invalid player card and insert valid offer cashless coupon

74 Card-in and insert a valid offer coupon

Play off all of the credits

Remove the player card

75 Card-in and insert a cashless coupon for valid date that was previously invalid (see scenario #17)


Play off part of the credits

Remove the player card and cash out remaining credits

77 Issue a point voucher and a point adjustment for guest

78 Card-in and insert an expired cashless coupon

79 Card-in and insert a valid pre-printed coupon



80 Valid card-in and an invalid cashless coupon


Insert additional coin-in

Play off all of the credits and part of the additional coin-in


82 Issue comp reward for guest 83 Card-ins for the same guest using

two slot machines; same player card in each machine

Insert a valid cashless coupon in one of the machines


Insert additional



- 23 -



coin-in and all of the additional coin-in

85 Card-in and insert a voided coupon

86 Card-in and insert a valid coupon Insert additional coin-in

Play off part of the credits and all of the additional coin-in


87 Attempt to redeem a cashless coupon from a non-valid property

88 Redeem a non-cashless coupon using the pdb offers screen for a guest with cashless coupons

89 Redeem an offer with a ptc using the offers screen for a guest with cashless coupons

90 Attempt to redeem altered cashless coupons

91 Attempt to manually redeem a cashless coupon using the pdb offers screen

92 Card-in and insert valid cashless coupon for guest who has an earlier card-in/coupon request at another property

93 Card-in and insert valid cashless coupon for guest who has an earlier card-in/coupon request at multiple other properties

94 Use various search/sort commands for cashless coupons

95 Redeem a cashless coupon from the AS/400 user screen

96 Void a pre-printed coupon from the AS/400 user screen

97 Redeem invalid cashless coupon for the local property

98 Redeem cashless coupon for invalid dates

99 Redeem non-cashless coupons using the speed offer redemption screen

100 Attempt to redeem a cashless coupon using the speed offer redemption screen

101 Switch active side from a to b 102 Complete a cms combine 103 Complete a full WINet® combine 104 Card-in and rating for guest with

cashless coupons

105 Card-in and insert a valid cashless coupon for guest

106 Insert player card for guest with cashless coupons – WINet® service providers down

- 24 -



107 Access the AS/400 employee screens with the WINet® service providers down

108 Insert player card and cashless coupon for guest (1st card-in) – WINet® service providers down

109 Insert cashless coupon for guest during trip for redemption (coupon request occurred with previous card-in) – WINet® service providers down

110 PDB attempt to send synch record to requesting CMS – WINet® service providers down

111 Card-in for guest with cashless coupons

112 Card-in and insert cashless coupon for guest (next card-in since WINet® up again)

113 Insert player card for guest with cashless coupons – WINet® down

114 Insert player card and cashless coupon for guest (1st card-in) – WINet® down

115 Refresh all slot coupons (after SDS database has been cleared)

116 Process WINet® extracts 117 Process WINet® synch 118 Use automated multi-scan to

process slot drop

119 Use of soft count “manual” scanners to process cashless coupons (CC)

120 Run SDS reports 121 Card-in and redeem cashless

coupon for 2 guests simultaneously

122 Card-in for guest with cashless coupons for valid and invalid dates

123 Card-in for guest with altered cashless coupon

124 Run purge of the transaction log, card-in frequency file and response time log

125 Run purge of the offermail, offermbrs, capcoupon and capcpnmbrs files

126 Remove a vendor file and void the pre-printed coupons

127 Verify that the service providers are up and running

Verify the offer windows codes is loaded on the pc

Verify the PC can communicate with WINet® through topend

Make sure that all validation/posting modules from checkpoints above are running and make sure to load the dest_tape table with test data

- 25 -



128 129 Create a new offer, retrieve the

offer after creation, mail the offer and save the offer as a new offer

130131

Other Areas Not Tested Undocumented Features: Not responsible for bugs appearing in undocumented or non-maintained areas of the

PDB system External Project Impact: Not responsible for bugs dependent on released up coming project releases. Any bugs

that are found in those releases will be reported to the respective project group. Backend Data Maintenance: AIX Server/Informix backup and recovery, daily disk space/db size maintenance,

routine archiving, data warehouses, etc.

Features/Functionality Tested

#TestingPriority

Size(1-10)1=small Feature Name Feature Description

1 H 5 …2 M 5 …3 L 2 …45

6789

1011121314

Features Not TestedThe following items will not be tested by the Harrah’s Entertainment, Inc. during this PDB AIX upgrade project:

1. Any new functionality or related new systems scheduled for release soon (by end of 2004) such RG II (although some limited tests may be done here if decided)

2. Top End Certification on AIX 5.2 (responsibility of TTM vendor now in conjunction with Richard Thomas)3. 4th Tier functionality, etc. (???)

- 26 -

See the Initial List of Test Scenarios above (from John McGowan – these will be tested first in the order below) – THIS ‘Features Tested” table will be completed at a later date



Test Director Parts and “Test Tree”

TD_PDBUptimeImprovements (project name in Test Director)

Requirements

Test Plan

Test Lab

Defects

- 27 -



Test Tree (tentative)

Area

Project Name (on tree) Details Design

Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

FOHWINet® PDB

Build Tests1. Preliminary2. Check current AIX System for

corruption3. Make sure the Installed Licensed

Program Products are consistent4. Make sure no filesets have been

broken5. Make sure all of the user definitions

are correct in the user database6. Check CD ROM and other firmware

for compatibility7. Check adapters for compatibility8. Check system space9. Check removal of AIX Toolbox for

Linux applications if installed10. Check type of kernel for correct

support of adaptors and power management

11. Check that PDB applications will work on 5.2 and are compatible (check that are recompiled for 5.2)

12. Recompile files where file formats have changed on 5.2—esp. 32 bit apps

13. Check for files linked statically or apps dependent on undoc’d or unsupported interfaces – correct where necessary

14. Check that recompile done for apps and libraries for use on 64 bit programs & Modify existing 32 bit kernel extension and device drivers for 64 bit ABI use

15. Identify kernel services in 32 bit where services for the are no longer provided in 64 bit—these have to be ported to use with 64 bit

16. Check device drivers for I/O where kernel extensions supported in 32 bit are NOT supported in 64 bit – correct where necessary

17. Run a test migration of all programs to 5.2

18. Check for obsolete filesets (for binary compatibility)

19. Smoke Tests20. Check three types of batch

processing are working, namely:21. Data files come in from remote

systems and are submitted to the batch processing service

22. Data is extracted from the central PDB and shipped to parallel servers at the properties

23. Extracted data is used to create databases on the parallel servers

24. Check code tables updating25. Check compiler and debugger

extensions needed for the PDB work

- 28 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

26. Check various environment services (service extensions)

27. Check error handling services28. Check logging services29. Check profile management services30. Check task management services31. Check configuration management

services32. Check dynamic tracing services

required for PDB namely:33. The ability to toggle on/off tracing

routines in running application programs

34. The ability to see, at a function level, exactly how a program is flowing

35. The ability to see, at a function level, crucial variables internal to the program

36. Check services required in the gateway between the AS400 and the PDB Brand Server

37. Check communications with the PTEC400 interface on the AS400 though the Inbound Agent on one side and with Top End services in the Brand Server on the other side

38. Check Harrah’s Report Printing Services Application Programming Interface (HRPT API), for:

39. The ability to set up the page height and width and have the API handle the report header and footer and pagination automatically

40. The ability for the API to create the print filter-required file and line headers automatically, but to be able to override these if necessary

41. The ability to dynamically change the line spacing (1-3)

42. Support for a user-specified header at any point that will be in addition to the standard header and may be printed at any point on demand

43. Check MWB extracts44. Check PAMS messages45. Check that system will handle

segments in groups when parsing a message

46. Check database caching services as required for PDB

47. Must be able to cache all or part of a table.

48. Must be able to change the caching parameters (i.e. number or rows cached) at initialization

49. Must use write-through methods to maintain database integrity

50. Must use locking to ensure that updates do not occur in the middle of a read.

51. Must gather statistics on the functioning of each cache (toggled on/off dynamically)

52. Database primitives53. Database services required for PDB54. The ability to load the database55. The ability to access data in a

structured (SQL) fashion.56. The ability to access data in a fast,

efficient manner in a transaction oriented environment

- 29 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

57. The ability to provide database maintenance operations

58. The ability to backup the data59. UNIX remote file I/O services

necessary in the Patron Database60. Different sets of variables to transfer

and process the file correctly61. Promus Message Logger, which

provides error handling and logging services for PDB

62. The ability to log errors from all of the hardware platforms into the Top End console log

63. The ability to have multiple error levels. Some would, in effect, be warnings.

64. Top End (TE) operational features effectively run and manage the OLTP system

65. The ability to stop/start jobs66. The ability to suspend/resume jobs67. The ability to query running jobs,

and obtain information such as:68. Response time69. Number of users (for Top End

complex servers)70. Resource consumption71. The ability to turn on/off dynamic

tracing72. Printing services 73. The ability for a Windows

workstation user to request a report from a service and have the report directed back to a local printer.

74. The ability for a Windows workstation user to request a report from a service and have the report directed to print on an AS/400 printer.

75. The ability for a Windows workstation user to print locally generated files (ASCII or binary) and print them on a local printer.

76. The ability for an AS/400 terminal user to request a report from a service and have the report directed back to a printer attached to an AS/400.

77. The ability for support personnel to be able to print from UNIX machines to local Windows workstations.

78. Statistics gathering services required for PDB

79. The ability to toggle on/off statistics routines in running application programs.

80. The ability to see, at a function level, exactly how efficiently a program is functioning

81. The ability to see, at a function level, performance statistics internal to the program

82. The ability to log statistics into a common statistical database

83. Stopwatch routines providing highly detailed timing for debugging, maintenance, and statistics gathering

84. The ability to maintain multiple stopwatches in any given process

85. The ability to initialize a stopwatch

- 30 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

86. The ability to read the elapsed time on a stopwatch. Also to be able to easily convert this value to other time units.

87. The ability to read the 'lap' time on a stopwatch (the elapsed time since the last read).

88. PTEC89. The ability to share data between

RPG and 'C' programs on the AS/400

90. Statistical and Environment Control Services for the AS400

91. Communications between a Unix System and an AS/400 partner on a Token Ring network

92. Service providers (SPs)93. Service requesters (SRs)94. Shared semaphore routines for the

PDB95. Shared message routines for the

PDB96. Unit Testing

(SPFs)97. PFSSTAT ?98. BTCHSCH Sets up the RTQ workflow for batch

processing for the different files99. CUX201 Guest game processing/posting100. CUX212 Guest trip processing/posting101. CUX221 Guest comp processing/posting102. CUX230 Posts guest currency information103. CUX245 Reward credit balance

processing/posting104. CUX250 Tier score processing/posting105. DDP101 Calls stored procedures to perform

the106. EUX210 Posts event detail records107. EUX211 Posts event ticket block records108. GEX255 Extracts guests for NCOA

processing109. GEX258 Guest bank info to CMS110. GEX259 Generates the lists of ids for guest

sync111. GEX260 Creates the actual extracts for CMS112. GUX210 Guest master posting113. GUX211 Processes guest master suspense114. GUX220 Guest bank posting115. GUX230 W2g posting116. GUX240 Guest message posting117. GUX250 Guest interest posting118. GUX260 Merge/Purge processing119. GUX270 CMS only combines120. GUX270B Full WINet® combines121. GUX280 Y-susp combine processing122. GUX300 Calculates guest reward credits123. HUX210 Hotel stay extract posting124. OFB200 Offer mail file generation125. OFB201 Secure offer mail file transfers126. OFB202 Cashless black-out date functionality127. OFB300 Initiates messages to start mail file

processing128. OFB400 Processes offer redemptions from

extract files129. OFB500 Offer retraction process130. OFR902 Loads guests into the paradb table131. OFR903 Does validation on potential

var_coup_amt records132. OFR904 Loads guests into the paradb table

and the recp group table133. OFRBAT ?134. PMX910 Used to execute a "system" call

- 31 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

from within Top End135. PUX100 Traffic cop for daily batch file

processing136. PUX101 Updates the transmit log table with

correct status for batch files.137. PUX145 Processes the event master file138. PUX146 Processes the hotel group code file139. PUX147 Processes the event date/time file140. PUX149 Processes the event ticket block file141. PUX150 Processes the guest bank file142. PUX151 W2G processing143. PUX152 Processes the guest message file144. PUX153 Guest master processing145. PUX154 Processes the guest interest file146. PUX155 Processes the guest currency

extract147. PUX158 Event trip processing148. PUX159 Hotel stay extract processing149. PUX160 Posts 9 different input files (event &

hotel)150. PUX400 Reads from pdb_trip_candidate and

creates appropriate TE/PAMS message

151. PUX400B Transitions properties from 5 to 6152. PUX401 Processes Trip, Shortened Trips,

Deleted trips, comp and rating records

153. PUX410 ?154. PUX420 ?155. PUX430 ?156. PUX440 ?157. PUX450 ?158. PUX515 ?159. PUX515B Transitions properties from 3 to 4160. PUX520 ?161. DDP100 Places message for DDP101 on

Queue162. GSX510 Guest select163. GSX515 Guest trip summary select164. GSX520 Guest trip summary select165. GSX521 Guest trip detail summary - for

PCS ?166. GSX525 Information for the Play Detail

Screen167. GSX530 Information for the comp detail

screen168. GSX535 Guest message select169. GSX540 Guest credit information170. GSX545 Guest bank information171. GSX550 Guest personal information172. GSX555 Guest hotel information173. GSX565 Guest interest information174. GSX585 Guest links information175. GSX610 Retrieves cashless coupons for

guests on card in176. GSX620 Something to do with cashless177. GSX630 Repsonds to a sync request to

supply updates for cashless coupons

178. GSX640 Guest cross-reference information179. GUX285 Online susp merge purge180. GUX570 Manual tier updates181. GUX580 Manual guest add/update from guest

master screen182. GUX581 Maintain some guest preferences183. GUX582 Maintain the other guest preferences184. GUX590 Online WINet® Merge/Purge185. OFR050 Retrieves offer detail information186. OFR100 Offer modification/creation187. OFR150 Populates the offer list window in

Win client

- 32 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

188. OFR200 Mail generation/regen message189. OFR350 Supports coupon functions190. OFR351 Supports vendor functions191. OFR400 Reserves/redeems/voids/

unredeems coupons192. OFR401 Redemption or invalidation of offer193. OFR402 Retract offer/delete

collateral/remove individual/ remove collateral

194. OFR450 Maintenance for offer cost table195. OFR500 Collateral maintenance196. OFR550 Collateral associate maintenance197. OFR551 Cashless blackout date

maintenance198. OFR600 Recipient group maintenance199. OFR650 Recipient group association

maintenance200. OFR700 RG associate collateral201. OFR750 Add individual to RG202. OFR810 Recipient group maintenance203. OFR820 Deletes group of guests from rgs204. OFR850 Selects offer sent/redeemed

information for a guest205. OFR851 Retrieves offer information206. OFR900 Paradb list maintenance207. OFR901 List transfer program208. OFR950 Returns collateral/coupon info for

offer209. OFR951 Internet effective date210. PMX900 PF4 lookup functionality211. PRX510 Provides listing of available reports212. PRX515 Provides list of available print

queues213. PRX520 Provides list of re-printable reports214. PRX525 Reprints reports w/o regeneration215. PRX530 Report submit module216. PRX550 Provides list of event reports217. PRX560 Provides list of groups and group

types available for printing218. PUX570 Provides the details for the Windows

suspense processing application219. CRF470 Wholesale group summary report220. CRF475 Looks like an event report221. ERF410 Room event summary222. ERF415 Event/ hotel/ gaming activity for

event223. ERF420 Room event comparison report224. GRF405 Address standardization error log by

property225. GRF407 Address standardization error log by

brand226. GRF410 Address change audit log227. GRF415 Online accounts combine audit log228. HRF420 Hotel group summary information229. HRF465 Source group summary report230. HRF475 Source group summary totals report231. ORF405 Offer assignment exceptions232. ORF410 Offer summary estimate report233. ORF415 7 day offer redemption report234. ORF455 Offer redemption report235. ORF465 Reserve/redeem offer report236. PRF400 Report of susp_guest table237. PRF410 Report of susp_trip table238. PRF411 Report of trans summary susp _trip239. PRF412 Report of susp_comp table240. PRF413 Report of susp_curr241. PRF415 Report of susp_event242. PRF416 Report of transaction summary

susp_event_trip243. PRF417 Report of susp_event_date_time244. PRF418 Report of susp_evt_tktblk

- 33 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

245. PRF419 Report of susp_event_trip246. PRF420 Report of susp_group247. PRF421 Report of susp_hotel248. PRF422 Report of susp_intr249. PRF423 Report of susp_message250. PRF424 Report of susp_w2g251. PRF455 Cross property visitation report252. PRF460 File transmission report for Ops253. PRF470 Possible casino combine report254. PRF480 Cross property visitation w/ Dom

prop255. Regression

(system) testing256. PDB257. Player Rating & Comps258. Player Preferences259. Trip Histories260. Player Messages261. Player Credit Information262. Offer Management263. Address/Account Standardization

and Consistency264. All combines for CMS/LMS/EMS265. WINET® available266. WINET® combine267. WINET® down268. WINET® extract processing269. WINET® synch processing270. CMS271. Collection and storage of point

information272. Collection and storage of local play

information273. CMS combine274. Comp profiling - (control accounts)275. Point transactions - (control

accounts)276. Auto-activation - (control accounts)277. Kiosk278. Point balances, redemptions279. SDS280. Customer point balances SDS –

switch sides281. SDS refresh282. LMS283. Hotel offers284. Posting of hotel offers285. Offers reservations/redemption 286. EMS287. Events offers288. Offer reservations/redemption289. Food/Retail Comp redemption290. Top End291. Messages292. Connectivity293. Load balancing294. Top End Gateways295. Communications to CMS/LMS/EMS

through SNA and PDB through TCP/IP

296. Messages, status, etc.297. Primitives298. DB Primitives299. DB/SQL300. SQL301. Database lookups for multiple uses302. Complex queries written for a

specific usage303. Basic SQL queries written for a

specific usage304. PAMS

- 34 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

305. Formatting and communication of messages between systems

306. End of day processing307. PDB Batch

Applications308. Guest Add/Change/Delete309. Daily Play information310. Comp redemptions311. Hotel stays312. Events313. PDB Trip Combine 314. Batch Movement to MWB315. National Change of Address

(NCOA)316. Nightly Process317. NCOA318. Outside mailing list updates

processing319. Updates320. Merge/Purge candidate table321. Merge/Purge322. Consolidation of duplicate guest

information into one guest record323. Check adds/changes324. Shrinking of candidate table and

qualifying of pairs. 325. On-line combine to combine 2 guest

records manually326. Purge Process327. Offers328. Definition, tracking and reporting on

promotional offers sent to customers329. Receipt of offer control files from

client workstations330. Offer definition and assignment of

Ids331. Creation of mail files & export of

same to AS/400332. Mail files are transferred to vendor

for actual offer distribution to customer - Create tape version and e-mail version

333. Offer - un-redemption334. Offer display335. Offer mail file336. Offer mail file – volume tests337. Offer re-mail338. Offers – PC client339. PTC offer redemption - (control

accounts)340. Coupon (PTC) redemption341. Coupon (regular) redemption342. Coupon redemption343. Coupon redemption - (re-test)344. Coupon refresh345. Coupon request346. Speed offer redemption347. Pre-printed coupons348. Redemption synchronization349. Card-in/coupon request - volume

test350. Property participation351. Vendor file void352. Create a brand offer (#1) without

cashless coupons for a list of guests for valid testing date range

353. Create a brand offer (#2) with fixed cashless coupon amounts for a list of guests

354. Add collateral to brand offer #2 with variable coupon amounts and black-

- 35 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

out dates355. Add collateral to brand offer #2 valid

only at one property with variable cashless coupon amounts and with black-out dates

356. Offers display on WINet® screens appropriately

357. Offers display on Internet appropriately

358. Create an offer with coupons for a large list of guests

359. Create pre-printed coupon file for each valid denomination and valid testing date range

360. Create pre-printed coupon file for each denomination and not valid for testing date range

361. Redeem a non-cashless coupon using the PDB offers screen – property does not participate in MPCI (sypcn flag set to ‘n’)

362. Redeem an offer with a PTC using the offers screen – property does not participate in MPCI (sypcn flag set to ‘n’)

363. 1st card-in and rating for a guest with an offer without cashless coupons – property participates (sypcn flag set to ‘y’)

364. 1st card-in and rating for guest with cashless coupons for valid dates

365. 1st card-in and rating for guest with cashless coupons for valid and invalid dates

366. Card-in and rating for guest with cashless coupon

367. Run nightly batch jobs, send winet®® extracts

368. Generate volume card-in/coupon requests

369. Attempt to modify cashless coupon amounts that have already been mailed

370. Attempt to modify black-out dates for an offer that has already been mailed

371. Retract an offer with cashless coupons that has been “mailed”

372. Add accounts to brand offers with cashless coupons that have already been “mailed” and re-mail

373. Redeem offer with PTC for guest374. Un-redeem a non-cashless coupon

for a guest375. Card-in and insert valid pre-printed

coupon 376. Card-in and attempt to redeem a

cashless coupon that was previously redeemed at the slot machine

377. Card-in and insert valid offer cashless coupon

378. Insert valid offer cashless coupon without a player card

379. Card-in with an invalid player card and insert valid offer cashless coupon

380. Card-in and insert a valid offer coupon

381. Card-in and insert a cashless coupon for valid date that was

- 36 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

previously invalid (see scenario #17)382. Card-in and insert a valid offer

coupon383. Issue a point voucher and a point

adjustment for guest384. Card-in and insert an expired

cashless coupon385. Card-in and insert a valid pre-printed

coupon386. Valid card-in and an invalid cashless

coupon387. Card-in and insert a valid offer

coupon388. Issue comp reward for guest389. Card-ins for the same guest using

two slot machines; same player card in each machine

390. Card-in and insert a valid offer coupon

391. Card-in and insert a voided coupon392. Card-in and insert a valid coupon393. Attempt to redeem a cashless

coupon from a non-valid property394. Redeem a non-cashless coupon

using the PDB offers screen for a guest with cashless coupons

395. Redeem an offer with a ptc using the offers screen for a guest with cashless coupons

396. Attempt to redeem altered cashless coupons

397. Attempt to manually redeem a cashless coupon using the pdb offers screen

398. Card-in and insert valid cashless coupon for guest who has an earlier card-in/coupon request at another property

399. Card-in and insert valid cashless coupon for guest who has an earlier card-in/coupon request at multiple other properties

400. Use various search/sort commands for cashless coupons

401. Redeem a cashless coupon from the AS/400 user screen

402. Void a pre-printed coupon from the AS/400 user screen

403. Redeem invalid cashless coupon for the local property

404. Redeem cashless coupon for invalid dates

405. Redeem non-cashless coupons using the speed offer redemption screen

406. Attempt to redeem a cashless coupon using the speed offer redemption screen

407. Switch active side from a to b408. Complete a cms combine409. Complete a full WINet® combine410. Card-in and rating for guest with

cashless coupons411. Card-in and insert a valid cashless

coupon for guest412. Insert player card for guest with

cashless coupons – WINet® service providers down

413. Access the AS/400 employee screens with the WINet® service

- 37 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

providers down414. Insert player card and cashless

coupon for guest (1st card-in) – WINet® service providers down

415. Insert cashless coupon for guest during trip for redemption (coupon request occurred with previous card-in) – WINet® service providers down

416. PDB attempt to send synch record to requesting CMS – WINet® service providers down

417. Card-in for guest with cashless coupons

418. Card-in and insert cashless coupon for guest (next card-in since WINet® up again)

419. Insert player card for guest with cashless coupons – WINet® down

420. Insert player card and cashless coupon for guest (1st card-in) – WINet® down

421. Refresh all slot coupons (after SDS database has been cleared)

422. Process WINet® extracts423. Process WINet® synch424. Use automated multi-scan to

process slot drop425. Use of soft count “manual” scanners

to process cashless coupons (CC)426. Run SDS reports427. Card-in and redeem cashless

coupon for 2 guests simultaneously428. Card-in for guest with cashless

coupons for valid and invalid dates429. Card-in for guest with altered

cashless coupon430. Run purge of the transaction log,

card-in frequency file and response time log

431. Run purge of the offermail, offermbrs, capcoupon and capcpnmbrs files

432. Remove a vendor file and void the pre-printed coupons

433. Verify that the service providers are up and running

434. Create a new offer, retrieve the offer after creation, mail the offer and save the offer as a new offer

435. Suspense Components

436. Process WINet® Suspended Records

437. Process CMS Suspended Records438. Guest Merge Suspense Update439. Check Event (type)440. Check Event Ticket Block441. Check Event Date Time442. Check Event Trip443. Check Hotel Group444. Check Hotel445. Check Bank446. Check Casino Comp447. Check Casino Currency448. Check Casino Game449. Check Casino Guest

- 38 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

450. Check Casino Interest451. Check Casino Message452. Check Casino Trip453. Check W2G454. MWB Components455. Movement of data between PDB

and MWB456. Detail Layer457. Summarization458. Cognos Impromptu459. Query Tool to access data460. Lists for analysis and offers461. Catalog462. Logical views of the data463. Impromptu

Client464. Point/Click interface465. Submission of queries to Impromptu

Request Server466. Impromptu

Request Server467. That each PC is connected to one

“instance” of Request Server468. WINet® Reporting

Components469. Hotel Group Summary 470. Offer Assign Exceptions 471. Address Changes Audit Log472. Show Room Events Compare473. Show Room Events Week to Week474. Wholesale Group Summary475. Guest Recognition

Components476. Retrieve guest by Winner® ID477. Retrieve guest by full name478. Retrieve guest by partial name.479. Retrieve guest by phone number480. Retrieve guest by social security

num.481. Retrieve guest by credit card num.482. Retrieve guest by drivers license

num.483. Retrieve guest trip summary484. Retrieve guest trip detail 485. Retrieve guest messages486. Retrieve guest credit information487. Retrieve guest bank information488. Retrieve guest personal information489. Retrieve guest interest inquiry 490. Retrieve guest maintenance 491. Retrieve guest address list492. Retrieve guest offer sent list493. Retrieve guest interest maintenance494. Retrieve guest hotel495. Retrieve guest links496. Retrieve a guest using full name of

guest497. Retrieve guest links, flip between the

links and retrieve the secondary account information

498. Retrieve a guest using a partial name

499. Retrieve a guest using a phone number

500. Retrieve a guest using a social security number

501. Retrieve a guest using a credit card number

502. Retrieve a guest using a drivers license number

503. Security

- 39 -



Area


Steps

Test Scrip

t

Attachments

Reqs Coverag

e

Defects

Maintenance Components

504. Create or delete a user profile505. List of screens a user profile

currently can access506. Allow screen access additions or

deletions for a specific user profile507. Allow a current user file access to

be copied for a different user profile508. Setup of a default printer outq for

each user profile509. AS/400 user

screens510. Internet display

- 40 -



Test Environment

Hardware

Testing will have access control to one or more PDB application/database servers separate from any used by non-test members of the project team. Testing will also have access control to an adequate number of variously configured PC workstations to assure testing a range from the minimum to the recommended client hardware configurations listed in the project’s requirements, functional specification and design specification documents.

Software

In addition to the application and any other customer specified software, the following list of software should be considered a minimum:

MS Office 2000 Professional MS Outlook Test Director

Operating Systems

The Project will be tested in:

AIX 5.2 Informix 7.2 Etc.

The Project will NOT be tested in or against:

Any future PDB environments containing functionality/features now under development but not yet released – the environment for PDB testing on the AIX upgrade will be “frozen” at a decided time; hence testing will only be against what is included in that “frozen” environment

Test Schedule

Milestone ListBelow is a list of milestones that testing will track for actual dates vs. scheduled dates.

Schedule# Milestone Name Sched’d

DateActual Date

1 Planning Phase Starts 13 9 04 13 9 042 Planning Phase Ends3 Upgrade (to AIX 5.2) Phase Starts4 Usability Testing5 Upgrade Complete6 Upgrade Phase Ends7 System Testing Phase Starts

- 41 -



8 System Testing Phase Complete9 Stabilization Phase Starts10 Release to Production11 Project Post Mortem121314151617

AssumptionsThe following assumptions were used to develop this test plan and the test schedule:

Requirements and functional specifications are complete, current, and stable Engineering will run a verification test for each upgrade build, including unit tests of any code changed as a results

of problems found with operating the existing PDB system on AIX 5.2 Engineering will also run any integration tests of any builds for supplemental utilities that they build or add to the

PDB system as a result of the AIX 5.2 upgrade PDB is assumed friendly, reliable, and responsive, without major functional flaws at this time on the current AIX

4.3.3 operating system/build ??? ???

Risks Requirements and functional specifications may not be adequately detailed to generate detailed test cases—

however there are already a sufficient number of system level test cases from previous projects that are available for most areas of concern and importance to ensure a thorough test of the PDB system on AIX 5.2

The possibility that Testing’s allotted time will be cut short. The mitigation strategy is to organize test cases in Test Director by level and to test the higher-level test cases first, leaving the lower level ‘Standard’ and ‘Suggested’ test cases until time permits their execution.

Completely “freezing” the PDB application for testing; there may be a “gap” between the PDB that is actually tested compared with the one that will be in production at the time the upgrade occurs – all variations between the test and the production system need to be noted at the time of “going live” with PDB on AIX 5.2 – this is the greatest risk factor known at this time as there may be new functionality that misses being testing for reasons of not having an exact copy of the production system at some point on the test system

Simulating an exact copy of production data on test with enough load and data types to execute all possibilities than may occur under various conditions – this risk must be mitigated by having large enough data extracts from the production system to “cover” all possible functions and scenarios that may occur, especially under conditions that occur less frequently, whatever they may be

Having an adequate number of “testers” to enter all test scripts on a timely basis and to make sure that all prerequisite conditions (from earlier test scripts in the testing cycle) exist so that the entire life cycle of PDB can be properly simulated in the test environment

Test DeliverablesTesting will provide specific deliverables during the project. These deliverables fall into three basic categories: documents, test cases/bug write-ups, and reports. Here is a diagram indicating the dependencies of the various deliverables:

- 42 -



Require-ments [PM]

Project Plan[PM]

FunctionalSpec [PM]

Test Plan Test Spec./ Outline

DetailedDesign[Dev]

TestCases

Bugs

BugResults

TC CoverageReports

Bug Reports

WeeklyStatusReports

Test CaseResults

As the diagram above shows, there is a progression from one deliverable to the next. Each deliverable has its own dependencies, without which it is not possible to fully complete the deliverable.

The following page contains a matrix depicting all of the deliverables that Testing will use.

- 43 -



Deliverables Matrix

This matrix should be updated routinely throughout the project upgrade cycle in you project specific Test Plan.

Deliverable Milestone Sign-OffDocuments Test Approach Planning Test Plan Design Test Schedule Design Test Specifications DevelopmentTest Case/Bug Write-Ups Test Director Test Cases/Results All Test Director Coverage Reports All Test Director Bugs and Regression Results All Test Director Analyzer Bug Reports AllReports Weekly Status Reports All Phase Completion Reports All Test Final Report - Sign-Off Stabilization CD Archive Stabilization

Documents

Test Plan (see Appendix B for a copy of it as it exists now which is not complete nor finalized)

The test plan is derived from the test approach, requirements, functional specs, and detailed design specs. The test plan identifies the details of the test approach, identifying the associated test case areas within the specific Project for this release cycle. When this document is completed, the test lead will distribute it to Harrah’s Entertainment, Inc. project management for sign-off.

The purpose of the test plan document is to:

Specify the approach that testing will use to test the project and the deliverables (extract from the Test Approach). Break the project down into distinct areas and identify features of the project that are to be tested Specify the procedures to be used for testing sign-off and project release Indicate the tools used to test the project List the resource and scheduling plans Indicate the contact persons responsible for various areas of the project Identify risks and contingency plans that may impact the testing of the project Specify bug management procedures for the project Specify criteria for acceptance of development drops to testing (of builds)

Test Schedule

The test schedule is the responsibility of the test lead (or department scheduler, if one exists) and will be based on information from the project scheduler (done by the project manager). The project specific test schedule will be done in Test Director.

- 44 -



Test Specifications

A test specification document is derived from the test plan as well as the requirements, functional specs., and upgrade specs documents. It provides specifications for the construction of test cases and includes list(s) of test case areas and test objectives for each of the components to be tested as identified in the project’s test plan.

Test Case/Bug Write-Ups

Test Director Test Cases

Test cases will be documented in Test Director. Test cases are developed from the test specifications, functional specs., and design specs. Test cases are detailed at the lowest level of complexity. Results will be tracked as either pass or fail in the Test Director database. There must be an associated Test Director bug for every failed test case.

Test Director Coverage Reports

Test case coverage reports will provide the current status of test cases and pass/fail information. The reports can breakdown the status information across the different test case areas, by level (smoke, critical path, standard, suggested, etc.), and in other formats.

Test Director Bugs and Regression Results

Bugs found will be documented and tracked in the company-wide Test Director. There will be an associated test case (in Test Director ) for every Test Director bug written. Standards for writing up bugs are detailed in a later section entitled Test Director and Test Director database standards section of this document.

Test Director Analyzer Bug Reports

Reports from the Test Director analyzer (reports function) will be used to communicate information on all bugs to the appropriate project personnel.

ReportsThe test lead will be responsible for writing and disseminating the following reports to appropriate Harrah’s Entertainment, Inc. project personnel as required.

Weekly Status Reports

A weekly status report will be provided by the test lead to project personnel. This report will summarize weekly testing activities, issues, risks, bug counts, test case coverage, and other relevant metrics.

Phase Completion Reports

When each phase of testing is completed, the test lead will distribute a phase completion report to the project manager, engineering lead, and project manager for review and sign-off.The document must contain the following metrics:

Total test cases, number executed, number passes/fails, number yet to execute Number of bugs found to date, number resolved, and number still open Breakdown of bugs by severity/priority matrix

- 45 -



Discussion of unresolved risks Discussion of schedule progress (are we where we are supposed to be? Is there “scope creep,” project “slippage,”

etc. to ensure that all expected deadlines are going to be met)

Test Final Report - Sign-Off

A final test report will be issued by the test lead. It will certify as to the extent to which testing has actually completed (test case coverage report suggested), and an assessment of the project’s readiness for release to projection.

CD Archive

Once a project release cycle has been completed, all source code, documentation (including requirements, functional spec, design spec, test plan, etc.), all testware automation, etc. should be archived onto a CD for permanent storage.

Responsibility Matrix

TaskProgMgmt Dev Test

Prod.Mgmt

Who is Responsible

DateCompl’d

Project Plan S P Project ManagerProject Schedule P S Project ManagerRequirements S P Project ManagerFunctional Specification S P Project ManagerDetailed Upgrade Specification P EngineeringTest Approach P Test AnalystTest Plan P Test AnalystTest Schedule P Test AnalystSystem/Unit/Load/RegressionTest Plans

S S P Test Analyst

Test Director Test Cases & Results P Test AnalystTest Director Coverage Reports P Test AnalystTest Director Bugs P Test AnalystTest Director Bug Analyzer P Test AnalystWeekly Status Reports P P P P Test AnalystTest Final Report P Test AnalystCD Archive P Project Manager

P - Primary; S - Secondary

- 46 -



Test Methodology

Test Stages

Overview

There are four major milestones in the Harrah’s Entertainment, Inc. PDB AIX (to 5.2) upgrade cycle: the planning phase, upgrade/PDB build phase, testing phase, and stabilization phase. The planning phase culminates in the completion of the planning docs milestone (requirements plus functional specs). The upgrade phase culminates in the completion of the test plan/test specs. The testing phase culminates in the testing complete milestone. The stabilization phase culminates in the release to production milestone.

During the first two phases, Testing plays a supporting role, providing ideas and limited testing of the planning and upgrade documents. Throughout the final two stages, Testing plays a key role in the project. Note that Testing may not be completely involved or involved at all in the testing of the server with the new AIX 5.2 operating system installed as that is primarily the domain of Engineering.

Milestone 1 - Planning Phase

During the first phase of the upgrade cycle, testing should focus upon the requirements and functional specs. Testing reviews these documents for their comprehensibility, accuracy, and feasibility. Specific tasks that Testing may carry out during this phase include:

Assessing the impact of requirements on testing (although at this time no change in requirements is expected; however, in the event that there are requirements that change—primarily due to inclusion of any functions/changes now underway in other PDB related projects, we need to know if there will be any impact on this test plan/strategy—this would be a “scope creep” situation that would arise and have to be dealt with)

Providing metrics factors (preliminary schedule, estimated test case and bug counts, etc.) Identifying project infrastructure issues Identifying risks related to the testing and AIX upgrade process

Milestone 2 - Upgrade/PDB Build Phase

During the second phase of the upgrade cycle, testing is focused upon evaluating the upgrade/PDB build and is required to produce and distribute its draft test plan (although this task may be delegated solely to Engineering for test/verification that the AIX installation/build meets all vendor and Harrah’s requirements as to configuration, etc.). To generate the test plan, test specs, and test cases, Testing requires that the requirements, functional specs, design documents, business rules, and project plan/schedule be completed and a copy e-mailed to the test point person. Note that at this time, Testing has received the majority of these documents.

During this phase, testing may participate within the upgrade/build reviews (with Engineering) and have access to the upgrade specs for the PDB system under construction. This will help Testing better prepare its test plan, test specs, and test cases. The test plan defines much of the detailed strategy and specific testing information that will be used for testing the new PDB (upgraded O/S to AIX 5.2) application.

The purpose of the test plan is to achieve the following:

Divide upgrade specs into testable areas and sub-areas (do not confuse these with more detailed test specs); this step will also identify and include areas that are to be omitted (not tested)

Define testing strategies for each area and sub-area Define bug-tracking procedures Define release into testing and production environment criteria

- 47 -



Define list of configurations for testing Identify testing risks Identify required resources and related information Provide testing schedule

Milestone 2a - Usability Testing (Build Testing)

The purpose of usability testing is to ensure that the components and features will function in a manner that is acceptable to the clients or users. Engineering will create a functioning test system with the new components (AIX 5.2 operating system with PDB installed on top) to evaluate the proposed upgrade. Usability testing will be coordinated by Testing, but the actual (system/regression) testing will be performed by simulating an environment as close as possible to what current, everyday PDB use and operation is. Testing will review the findings and provide the project team with its evaluation of the impact these AIX upgrade changes will have on the testing process and the project as a whole.

Milestone 3a - Unit Testing (Multiple SPFs)

Unit testing will be conducted to the extent that it verifies unit operation as correct (SPFs).

This will be a lower priority in the testing cycle at this time—perhaps even being done “out of order” as shown in this document and done AFTER ALL OTHER TESTING is complete. Unit testing (unit-by-unit) will be done as it is during new development of units and/or code changes to the same if already in production.

Milestone 3b - Regression (System) Testing

Regression (system) testing is the evaluation of the existing PDB functionality that has been incorporated into the new build or upgrade to AIX 5.2. Several cycles of regression testing will occur. Completion of this phase will occur after the upgrade to AIX 5.2 is complete and will include only bug fixes with no new features or components to install (this is not fully decided yet as to what bug fixes will be included and/or done before release of AIX 5.2 with PDB into production).

Regression (system) testing will include:

Execution of Test Director test cases Documentation into the Test Director of any variations from expected results Addition of other needed test cases into Test Director

Milestone 4 - Stabilization Phase

Upon entering this phase, PDB has been internally unit and regression (system) tested module by module and function by function (again as stated in 3b above, note that unit testing at this point may have only been done at a “high level” without the individual testing “unit-by-unit” having been done yet—this is not fully decided at this time regarding to what extent unit testing will be done). The objective of this phase is to arrive at the release milestone with a completely reliable build. There is still an emphasis on Harrah’s Entertainment, Inc. however to continue to identify issues (bugs) and to regress the bug fixes. All project members, plus tech support colleagues may become involved in this process during this phase

Milestone 4a – Release into Production

Release into production will occur only after the successful completion of all tests throughout all of the phases and milestones discussed above. The milestone target is to place PDB (upgraded on AIX 5.2) into production after it has been shown that it has reached a level of stability that meets or exceeds the client expectations as defined in the Requirements, Functional Specs., and also according Harrah’s Entertainment, Inc.’s own internal I.T. standards.

Harrah’s Entertainment, Inc. Testing will ensure that all expectations and standards pass the following test cases:

- 48 -



Check for extra or missing files (Diff operation on directory). Proper date stamps on all files (Diff operation on directory). Binary comparison of source files Basic functionality tests (automated smoke tests).

Milestone 4c - Post Release

During this phase, Testing will archive all project documents, notes, test-ware (automated Test Director scripts, etc.), e-mail, source code, etc. Archiving is the responsibility of the test lead. Testing also prepares a post-implementation review document discussing the testing process throughout the upgrade cycle.

Test LevelsTesting of an application can be broken down into three primary categories and several sub-levels. The three primary categories include tests conducted for every build (build tests), tests conducted for every major milestone (milestone tests), and tests conducted at least once for every PDB function (system regression tests). The test categories and test levels are defined below:

Build Tests

Level 1 - Build Acceptance Tests

These test cases simply ensure that the upgraded application has been built and installed successfully. Other related test cases ensure that Harrah’s Entertainment, Inc. has received the proper technical and support documents plus any other build related information needed for future reference. The objective is to determine if further testing is possible by having a successful build test. If any Level 1 test case fails, the upgrade is returned to engineering un-tested.

Level 2 - Smoke Tests

These tests cases verify the major functionality at a high level. The objective is to determine if further testing is possible. These test cases should emphasize breadth more than depth. All components should be touched, and every major feature should be tested briefly by the Smoke Test. If any Level 2 test case fails, the upgrade is returned to engineering un-tested.

Level 3 - Bug Regression Testing

Every bug that was “open” during the previous build, but marked as “fixed, needs re-testing” for the current build under test, will need to be regressed, or re-tested. Once the smoke test is completed, all resolved bugs need to be regressed.

Milestone Tests

Level 4 - Critical Path Tests

Critical path test cases target features and functionality that the user will see and use every day. They do not need to be tested at every cycle, but must be tested at least once per milestone. Thus, the critical path test cases must all be executed at least twice during entire build and testing cycle.

Release Tests

Level 5 - Standard Tests

- 49 -



These are test cases that need to be run at least once during the entire test cycle. These cases are run once, not repeated as are the test cases in previous levels. Standard test cases usually include installation, data, GUI, and other test areas.

Level 5 - Suggested Tests

These are test cases that would be nice to execute, but may be omitted due to time constraints.Most performance and stress test cases are classic examples of suggested test cases (although some should be considered standard test cases). Other examples of suggested test cases include WAN, LAN, network, and load testing.

Bug RegressionBug regression will be a central tenant throughout all testing phases. All bugs that are resolved as “fixed, needs re-testing” will be regressed when Harrah’s Entertainment, Inc. is notified of the new build containing the fixes. When a bug passes regression it will be considered “closed, fixed”. If a bug fails regression, Harrah’s Entertainment, Inc. will notify engineering (or development) by entering notes into the Test Director. When a severity 1 bug fails regression, Harrah’s Entertainment, Inc. should also put out an immediate e-mail to engineering or development. The test lead will be responsible for tracking and reporting to engineering and/or development and to project management the status of regression testing.

It is recommended that a separate cycle of regression testing occur at the end of each build phase (if there multiple phases) to confirm the resolution of severity 1 and 2 bugs (yes, re-test them again). The scope of this last cycle should be determined by the test point person and project management (regress all severity 1 and 2, 50% of, 40% of, etc.)

Bug TriageBug triages will be held throughout all phases of the upgrade cycle. Bug triages will be the responsibility of the test lead. Triages will be held on a regular basis with the time frame being determined by the bug find rate and project schedules. Thus, it would be typical to hold a few triages during the planning phase, then maybe one triage per week during the build phase, ramping up to twice per week during the latter stages of the release to production phase. Then, the stabilization phase should see a substantial reduction in the number of new bugs found. Thus a few triages per week would be the maximum (to deal with status on existing bugs).

The test lead, project manager, and engineering lead should all be involved in these triage meetings. The test lead will provide required the documentation and reports on bugs for all attendees. The purpose of the triage is to determine the type of resolution for each bug and to prioritize and determine a schedule for all “to be fixed bugs.’ Engineering will then assign the bugs to the appropriate person for fixing and report the resolution of each bug back into the Test Director. The test lead will be responsible for tracking and reporting on the status of all bug resolutions.

Suspension Criteria and Resumption RequirementsTesting will be suspended on the affected software module when smoke test (level 1) or critical path (level 2) test case bugs are discovered. A bug report will be filed in Test Director and Harrah’s Entertainment, Inc. engineering and project management will be notified. After fixing the bug, engineering will follow the criteria (described above) to provide its latest upgrade or release to testing. At that time, testing will regress the bug, and if passes, continue testing the module.

Notice that some discretion is in order here on the part of the test lead. To suspend testing, the bug had better be reproducible; it had better be clearly defined; and it had better be significant.

Test CompletenessTesting will be considered complete when the following conditions have been met:

- 50 -



Standard Conditions:

When Harrah’s Entertainment, Inc. agree that testing is complete, the app is stable, and agree that the application meets functional requirements

Script execution of all test cases in all areas have passed Automated test cases in all areas have passed All priority 1 and 2 bugs have been resolved and closed Each test area has been signed off as completed by the test lead. 50% of all resolved severity 1 and 2 bugs have been successfully re-regressed as final validation Ad hoc testing in all areas has been completed (this is essentially the functional testing simulating the user view

and use of the PDB system)

Bug Reporting & Triage Conditions:

Bug find rate indicates a decreasing trend prior to zero bug rate (no new sev. 1/2/3 bugs found). Bug find rate remains at 0 new bugs found (sev. 1/2/3) despite a constant test effort across 3 or more days. Bug severity distribution has changed to a steady decrease in sev. 1 and 2 bugs discovered. No ‘Must Fix’ bugs remaining prior despite sustained testing.

Criteria for Acceptance into TestingFor a build/upgrade to be accepted for testing, the following items must be met:

Unit Testing: Each unit (SP) has to be tested by the engineering team before being released for further system/regression testing.

Existing Bugs Fixed: Developers must resolve all previously discovered bugs marked for fix. If there are too many unfixed bugs, which should have been fixed, then testing may reject the build.

Release Document: Must be issued for every new build (of Harrah’s in-house software). It will include the build number, all changes, and new features from the previous build. In a component release, it should indicate which areas are ready for testing, and which areas are not.

Instructions: All necessary setup instructions and scripts should be provided. Elements List: A list of all components (objects) in the current release with a version number.

- 51 -



Test Director (test case/bug/issue manager) and Test Director Database StandardsTesting has defined standards for the structure of and entry of data into both Test Director and Test Director. These standards will be adhered to in all projects.

Please review the Test Director User’s Manual for further details on Test Director. Please review your Test Director User’s Guide for additional information on the bug/issue tracking system (part of Test Director).

Test CasesHarrah’s Entertainment, Inc. test cases will be entered and administered in Test Director. The test lead will be responsible for the maintenance of Test Director. Testing will track and report the success or failure of the test cases. Tracking of test cases will include when tests were run, by whom, and code version/build number (if applicable) as well as any comments logged after the test case was run. The test lead will provide project management with reports.

Bug DocumentationAll bugs will be documented in Test Director. The Test Director description will follow the Harrah’s Entertainment, Inc. test case/bug write-up standard (included below). The Test Lead will be responsible for the maintenance of the Test Director database and bugs therein. All necessary project team members should have access to Test Director.

Every bug entered into Test Director will have an associated Test Director test case number associated with it. Where a bug does not fit into an existing test case, a new test case will be created and its number referenced in the Test Director bug entry. The new test case will have the ‘ADHOC’ flag set to true. Older cases may be updated to extend their potential for catching the new bug as long as it doesn’t significantly alter the objective of the original test case. In the event that a bug is found by a person outside if Harrah’s Entertainment, Inc. Testing, the bug should be reported to the test lead who will then assure that further testing is completed to verify the existence of the bug, refine the repro steps, and incorporate it into Test Director.

Bug Severity and Priority DefinitionBug Severity and priority fields are both very important for categorizing bugs and prioritizing if and when the bugs will be fixed. The bug severity and priority levels will be defined as outlined in the following tables below. Testing will assign a severity level to all bugs. The test lead will be responsible to see that a correct severity level is assigned to each bug.

The test lead, engineering lead and project manager will participate in bug review meetings to assign the priority of all currently active bugs. This meeting will be known as “bug triage meetings”. The test lead is responsible for setting up these meetings on a routine basis to address the current set of new and existing but unresolved bugs.

Severity List

The tester entering a bug into Test Director is also responsible for entering the bug severity.

Severity ID Severity Level Severity Description1 Crash The module/project crashes or the bug causes non-recoverable conditions.

System crashes, GP Faults, or database or file corruption, or potential data loss, program hangs requiring reboot are all examples of a sev. 1 bug.

2 Major Major system component unusable due to failure or incorrect functionality. sev. 2 bugs cause serious problems such as a lack of functionality, or insufficient or

- 52 -



unclear error messages that can have a major impact to the user, prevents other areas of the app from being tested, etc. sev. 2 bugs can have a work around, but the work around is inconvenient or difficult.

3 Minor Incorrect functionality of component or process. There is a simple work around for the bug if it is sev. 3.

4 Trivial Documentation errors or signed off severity 3 bugs.

Priority List

Priority ID Priority Level Priority Description1 Must Fix This bug must be fixed immediately; the project cannot go to production with

this bug.2 Should Fix These are important problems that should be fixed as soon as possible. It

would be an embarrassment to the company if this bug went into production.3 Fix When Have Time The problem should be fixed within the time available. If the bug does not

delay production rollout date, then fix it.4 Low Priority It is not important (at this time) that these bugs be addressed. Fix these

bugs after all other bugs have been fixed.

Bug ReportingTesting recognizes that the bug reporting process is a critical communication tool within the testing process. Without effective communication of bug information and other issues, the development and release process will be negatively impacted.

The test lead will be responsible for managing the bug reporting process. Testing’s standard bug reporting tools and processes will be used. Test Director is the company-wide standard bug logging/tracking tool. Testing and development will enter their data into the Test Director database following the field entry definitions defined below.

Bug Entry Fields

Bug Type

This field indicates what bug type was discovered. Bug types include:

Documentation: Bugs are those found in help files, user’s manuals, training guides, etc. (if applicable to the PDB Uptime project—this type may not be)

System Crash: Bugs are those that cause the application or the entire operating system to crash. These generally warrant a Severity 1 rating.

Trappable Errors: Are bugs that pop up an error box, but do not necessarily crash the application. These generally warrant a Severity 2 bug (although occasionally a sev 1 is appropriate).

User Interface: Bugs are those found in the graphical layout of the application. They typically include bugs such as controls that are not aligned, do not work, do the wrong action, etc.

Hardware: Bugs are those that an operation works with one set of hardware but fails under another hardware scenario.

Erroneous Output: Bugs are those in which reports have errors, data is processed incorrectly, etc. Suggestion: These *are* bugs that cannot be objectively identified, but rather are subjective opinions from experts

(testers) as to how a project can be improved.

Assigned To

This field contains a list of the names of the project team members to whom the bug is currently assigned. The person(s) in this field are expected to be doing their part to resolve the bug.

- 53 -



Project

This field contains the name of the Project under test from which the bug was born. A drop list provides the user with all permissible options.

Status

This field indicates the current bug status. The permissible values include: New: Status indicates a bug that was just discovered. Under Review: Status indicates a bug that is being reviewed and fixed by development. Testing In Progress: Status indicates a bug that is being re-tested, but will take time, or is awaiting some criteria

before it can be re-tested. Needs Re-Test: Status indicates a bug that has been fixed and is awaiting re-testing. Re-Review: Status indicates a bug that was fixed, re-tested, and found to still contain the error. Closed: Status indicates a bug that has been fixed, re-tested and passes verification. Yeah! The bug is fixed. Temp Deferred: Status indicates a bug that has been deferred until the patch release, etc.

Source

This field indicates who found the bug: testing, technical support, or other.

Priority

This field is a numeric indication of the importance of fixing a bug. It is typically set during bug triages in accordance with Harrah’s Entertainment, Inc. bug fix priority definitions (described earlier in this document). Values range from low, to medium (should fix), to high priority (must fix).

Severity

This field is a numeric indication of the importance of the significance that Testing places on this bug. Permissible values include 1 (crash), 2 (major), 3 (minor), and 4 (trivial). The severity ratings are described earlier in this document.

Code 1

Deferred: Outcome indicating that bug will be deferred until next release (postponed). By Design: Outcome indicating that bug was intended to act that way, and expected value is in fact the same as

actual value (thus, tester’s assertions for expected values were erroneous). Duplicate: Outcome indicating that bug already exists. Fixed: Status indicating that bug has been fixed. Not a Bug: Outcome indicating that bug was not truly a bug at all. Not Reproducible: Outcome indicating that bug was unable to be reproduced. Suggestion: Outcome indicating that bug is a suggestion that will not be implemented.

- 54 -



Appendix A

List of Unit Tests (scripts) on newdev

NEWDEV/WORK/SRC/PATRON1.0(in batch or online compared to SPF splits to show missing [in red] test scripts or not located on server at this time)

# SPF Directory Description Notes103 PFSSTAT ? ?1 BTCHSCH batch Sets up the RTQ workflow for batch

processing for the different files4 CUX201 batch Guest game processing/posting

5 CUX212 batch Guest trip processing/posting

6 CUX221 batch Guest comp processing/posting

7 CUX230 batch Posts guest currency information

8 CUX245 batch Reward credit balance processing/posting

9 CUX250 batch Tier score processing/posting

11 DDP101 batch Calls stored procedures to perform the

15 EUX210 batch Posts event detail records

16 EUX211 batch Posts event ticket block records

17 GEX255 batch Extracts guests for NCOA processing

18 GEX258 batch Guest bank info to CMS

19 GEX259 batch Generates the lists of ids for guest sync

20 GEX260 batch Creates the actual extracts for CMS

42 GUX210 batch Guest master posting

43 GUX211 batch Processes guest master suspense

44 GUX220 batch Guest bank posting

45 GUX230 batch W2g posting

46 GUX240 batch Guest message posting

47 GUX250 batch Guest interest posting

48 GUX260 batch Merge/Purge processing

49 GUX270 batch CMS only combines

50 GUX270B batch Full WINet® combines

51 GUX280 batch Y-susp combine processing

53 GUX300 batch Calculates guest reward credits

62 HUX210 batch Hotel stay extract posting

63 OFB200 batch Offer mail file generation

64 OFB201 batch Secure offer mail file transfers

65 OFB202 batch Cashless black-out date functionality

- 55 -



# SPF Directory Description Notes66 OFB300 batch Initiates messages to start mail file

processing67 OFB400 batch Processes offer redemptions from extract

files68 OFB500 batch Offer retraction process

92 OFR902 batch Loads guests into the paradb table

93 OFR903 batch Does validation on potential var_coup_amt records

94 OFR904 batch Loads guests into the paradb table and the recp group table

97 OFRBAT batch ?105 PMX910 batch Used to execute a "system" call from within

Top End132 PUX100 batch Traffic cop for daily batch file processing

133 PUX101 batch Updates the transmit log table with correct status for batch files.

134 PUX145 batch Processes the event master file

135 PUX146 batch Processes the hotel group code file

136 PUX147 batch Processes the event date/time file

137 PUX149 batch Processes the event ticket block file

138 PUX150 batch Processes the guest bank file

139 PUX151 batch W2-g processing

140 PUX152 batch Processes the guest message file

141 PUX153 batch Guest master processing

142 PUX154 batch Processes the guest interest file

143 PUX155 batch Processes the guest currency extract

144 PUX158 batch Event trip processing

145 PUX159 batch Hotel stay extract processing

146 PUX160 batch Posts 9 different input files (event & hotel)

147 PUX400 batch Reads from pdb_trip_candidate and creates appropriate TE/PAMS message

148 PUX400B batch Transitions properties from 5 to 6

149 PUX401 batch Processes Trip, Shortened Trips, Deleted trips, comp and rating records

150 PUX410 batch ?151 PUX420 batch ?152 PUX430 batch ?153 PUX440 batch ?154 PUX450 batch ?155 PUX515 batch ?156 PUX515B batch Transitions properties from 3 to 4

157 PUX520 batch ?10 DDP100 online Places message for DDP101 on Queue

25 GSX510 online Guest select calls gsx545 thru tp_dialog

- 56 -



# SPF Directory Description Notes26 GSX515 online Guest trip summary select

27 GSX520 online Guest trip summary select

28 GSX521 online Guest trip detail summary - for PCS ?

29 GSX525 online Information for the Play Detail Screen

30 GSX530 online Information for the comp detail screen

31 GSX535 online Guest message select

32 GSX540 online Guest credit information

33 GSX545 online Guest bank information called by gsx510 thru tp_dialog

34 GSX550 online Guest personal information

35 GSX555 online Guest hotel information

36 GSX565 online Guest interest information

37 GSX585 online Guest links information

38 GSX610 online Retrieves cashless coupons for guests on card in

39 GSX620 online Something to do with cashless

40 GSX630 online Repsonds to a sync request to supply updates for cashless coupons

41 GSX640 online Guest cross-reference information

52 GUX285 online Online susp merge purge

54 GUX570 online Manual tier updates

55 GUX580 online Manual guest add/update from guest master screen

56 GUX581 online Maintain some guest preferences

57 GUX582 online Maintain the other guest preferences

58 GUX590 online Online WINet® Merge/Purge

69 OFR050 online Retrieves offer detail information

70 OFR100 online Offer modification/creation

71 OFR150 online Populates the offer list window in Win client

72 OFR200 online Mail generation/regen message

73 OFR350 online Supports coupon functions

74 OFR351 online Supports vendor functions

75 OFR400 online Reserves/redeems/voids/unredeems coupons

76 OFR401 online Redemption or invalidation of offer

77 OFR402 online Retract offer/delete collateral/remove individual/ remove collateral

78 OFR450 online Maintenance for offer cost table

79 OFR500 online Collateral maintenance

80 OFR550 online Collateral associate maintenance

81 OFR551 online Cashless blackout date maintenance

82 OFR600 online Recipient group maintenance

83 OFR650 online Recipient group association maintenance

84 OFR700 online RG associate collateral

- 57 -



# SPF Directory Description Notes85 OFR750 online Add individual to RG

86 OFR810 online Recipient group maintenance

87 OFR820 online Deletes group of guests from rgs

88 OFR850 online Selects offer sent/redeemed information for a guest

89 OFR851 online Retrieves offer information

90 OFR900 online Paradb list maintenance

91 OFR901 online List transfer program

95 OFR950 online Returns collateral/coupon info for offer

96 OFR951 online Internet effective date

104 PMX900 online PF4 lookup functionality

125 PRX510 online Provides listing of available reports

126 PRX515 online Provides list of available print queues

127 PRX520 online Provides list of re-printable reports

128 PRX525 online Reprints reports w/o regeneration

129 PRX530 online Report submit module

130 PRX550 online Provides list of event reports

131 PRX560 online Provides list of groups and group types available for printing

158 PUX570 online Provides the details for the Windows suspense processing application

2 CRF470 reports Wholesale group summary report

3 CRF475 reports Looks like an event report

12 ERF410 reports Room event summary

13 ERF415 reports Event/ hotel/ gaming activity for event

14 ERF420 reports Room event comparison report

21 GRF405 reports Address standardization error log by property

22 GRF407 reports Address standardization error log by brand

23 GRF410 reports Address change audit log

24 GRF415 reports Online accounts combine audit log

59 HRF420 reports Hotel group summary information

60 HRF465 reports Source group summary report

61 HRF475 reports Source group summary totals report

98 ORF405 reports Offer assignment exceptions

99 ORF410 reports Offer summary estimate report

100 ORF415 reports 7 day offer redemption report

101 ORF455 reports Offer redemption report

102 ORF465 reports Reserve/redeem offer report

106 PRF400 reports Report of susp_guest table

107 PRF410 reports Report of susp_trip table

108 PRF411 reports Report of trans summary susp _trip

109 PRF412 reports Report of susp_comp table

- 58 -



# SPF Directory Description Notes110 PRF413 reports Report of susp_curr

111 PRF415 reports Report of susp_event

112 PRF416 reports Report of transaction summary susp_event_trip

113 PRF417 reports Report of susp_event_date_time

114 PRF418 reports Report of susp_evt_tktblk

115 PRF419 reports Report of susp_event_trip

116 PRF420 reports Report of susp_group

117 PRF421 reports Report of susp_hotel

118 PRF422 reports Report of susp_intr

119 PRF423 reports Report of susp_message

120 PRF424 reports Report of susp_w2g

121 PRF455 reports Cross property visitation report

122 PRF460 reports File transmission report for Ops

123 PRF470 reports Possible casino combine report

124 PRF480 reports Cross property visitation w/ Dom prop

- 59 -



Appendix B (examples only – not finalized, any info in this section)

Test Plan (draft – not complete; needs to be done in MS Project)

Known issues between AIX 4.3.3 and 5.2 (installation and migration related topics—these items below need to be include in the final Test Plan)

1. Check Current AIX System for Corruption: Make sure you have a stable system BEFORE you do the migration (migration means everything on 4.3.3 you'll run on 5.2). You need to make sure that your current level of AIX is stable, with no ODM corruption or fileset problems, before attempting.

2. Pre-migration Checks: Make sure the installed Licensed Program Products are consistent:

#lppchk v #lppchk c #lsvg rootvg

You should get no output from the preceding command. Any output is error output and should be corrected.

3. Make sure none of your filesets have been broken:

#lslpp l|grep BROKEN

Broken base filesets are corrected by forcing the install of the base fileset. Broken PTFs are corrected by reinstalling the PTF in the committed state.

4. Make sure all of the user definitions are correct in the user database:

#usrck n ALL

Do the same for the groups:

#grpck n ALL

If you find errors, you can correct them by replacing the n flag with the t flag.

5. Check CD ROM and other firmware! Make sure you check the CD ROM drive BEFORE you start, or the system may not boot:

# lscfg vl cd*

If Part number is 04N2964 and ROS level or ID is less than 1_04 you NEED to have the firmware upgraded FIRST (Retain Tip H1332). If the part number is not 04N2964 you should be fine.

Make sure your firmware on your disks and machine and devices is up to date. You will get an unrecognized client program format error if you do not have up-to-date firmware and result in a failure to boot from hard disk.

6. CHECK your adapters: Not all adapters are supported with 5L or in 64-bit mode

http://www 1.ibm.com/servers/aix/os/adapters/51.html

- 60 -



7. Check system space: You must have 64 megabytes of physical memory. Paging space for initial is 64 megabytes. You must have space for 5L. It is a much bigger kernel.

/ root 8 MGS (double of 4.3) /usr 385 MGS /var 4 MGS /tmp 32 MGS /opt 4 MGS (will be created if it doesn't exist.)

Dump space required based on memory: < 12 GB 1GB 12 <24 2GB 24 < 48 3GB >=48 4GB

8. Remove Software Packages: Remove any AIX Toolbox for Linux applications if you installed them before doing migration.

If you install bos.terminfo or other bos.terminfo.svprint.data, DO NOT attempt to remove or de-install once installed. This could cause errors and missing functions. You will get syschk Warning errors on installation.

9. Type of Kernel: The 32 bit kernel continues to be supported on 5L

64 bit Kernel support is available for the following POWER based systems: 7013 Model S70, S7A 7015 Model S70, S7A 7017 Model S70, S7A, S80 7025 Model H80, F80 7026 Model H70,H80,M80 7043 Model 260, 270 7044 Model 170,270 680 Model S85 640 Model B80 660 Model 6H1 620 Model 6F1

ALL MCA adapters are only supported on the 32 bit kernel. Power Management is only provided under the 32 bit kernel. 64 bit kernel limits support to 64 bit POWER based systems, while the 32 bit kernel supports both 32 and 64 bit kernel systems. All MCA machines will not be supported at AIX 5.2 or higher.

10. Application Support: Make sure that your application will work with AIX 5L.

It is advised that you try your applications on a demo machine or demo node BEFORE installing on a production machine. Here is some general information on compatibility:

The 64 bit kernel supports both 32 bit and 64 bit applications. Application source and binaries are portable between 5L 64 and 32 bit kernel systems.

Binary compatibility is provided for 32 bit applications running on earlier versions of AIX on POWER based systems, except for applications linked statically or applications dependent on undocumented or unsupported interfaces. Some system file formats have changed, and 32 bit applications processing these files MAY HAVE TO BE RECOMPILED.

To take advantage of scalability improvements to 64 bit programs, all applications and libraries must be recompiled on AIX 5l. In addition existing 32 bit kernel extension and device drivers used by 64 bit applications may have to be modified in order to support the new 64 bit ABI.

Kernel extensions for the 64 bit kernels run in 64 bit mode and have the scalability of larger kernel address space. Some kernel services available in 32 bit kernel are no longer provided by the 64 bit kernel, so existing 32 bit kernel extensions may have to be ported in order to be used with the 64 bit kernel.

Existing 32 bit kernel extensions continue to be supported by the 32 bit kernel, but these kernel extensions are not usable by the 64 bit kernel. Not all of the kernel extensions supported for the 32 bit kernels are supported for the 64 bit kernel, particularly device drivers for I/O.

11. A Word on MIGRATION: Migration is the default installation method for 32 or any versions of AIX Version 4 of the operating system to 5L. BE sure to do a mksysb and that it completed

- 61 -



successfully before starting. I really recommend doing that on a test machine before doing the actual production migration or even doing a complete overwrite install to be sure that everything makes it OK, but again, that is your choice. This is only my opinion.

12. YOU MUST BE sure that you are root and system for your group:

#lsuser a auth1 root

You can change the value if needed with : #chuser auth1=SYSTEM root

13. OTHER users who have access MUST BE LOGGED off before you begin. Make sure you document all routes, IP addresses, hostnames etc, before you begin . You should probably have a hard copy of your system, with all the settings, just in case.

14. After you do a shut down, first you must power off your machine and all devices, then turn the devices back on and make sure they are on before you proceed. The system will identify each peripheral during startup.

15. During the migration, the installation process determines which optional software products are installed on the existing version of the operating system. Components from previous releases that have been replaced by new software in 5L are installed at the 5L level.

16. If you were at 3.2, all files in the /usr/lib/drivers, /usr/lib/microcode, /usr/lib/methods and /dev are removed from the system, so non-device drivers must be reinstalled.

17. All AIX Windows interface composer, remote customer services, AIX Windows Development Environment, Display PostScript, Performance Tools and Open GL and graPHIGS are removed.

NOTE: You may have problems with your 32 bit applications if they had certain unsupported self-loadable kernel extensions, certain HFT interfaces, X11R3 input device interfaces, CIO LAN device driver interface, SCSI device configuration methods (IHVs), nlist subroutines, DCE threads, and applications compiled using POWER2 or POWER based compiler options, but executed on models other than POWER 2 or POWER.

18. Existing code may need to be recompiled. Binary Compatibility. If you do a migration install, you might notice that filesets on the system are in the OBSOLETE state. Obsolete filesets were installed by earlier versions of the operating system, but they remain on the current system because the migration only replaced some, but not all, of the files they contain. These filesets remain necessary for systems running mixed levels of the operating system.

19. Before you reload or install other software, shut down the machine and turn it off and then reboot or you will get kernel errors as in kernel is 4, software is 5.

Release notes:

http://publib.boulder.ibm.com/pseries/aixgen/relnotes/ext_relnotes.htm

5.2 notes:http://publib.boulder.ibm.com/pseries/aixgen/relnotes/52relnotes.current.html

No ID Task Name Work Duration Start Finish % Work Complete

1 PDB Uptime 0%2 Assessment 0%3 Write Test Plans 0%4 Create Test Data 0%

- 62 -

http://publib.boulder.ibm.com/pseries/aixgen/relnotes/52relnotes.current.html

http://publib.boulder.ibm.com/pseries/aixgen/relnotes/ext_relnotes.htm



5 Receive Hardware/Software/Software

0%

6 Hardware/Software Install 0%7 Hardware/Software Install

Complete0%

8 Load WINet® on AIX 5.2 Upgrade machine

0%

9 Unit Test AIX, Informix, TopEnd

0%

10 Software Changes 0%11 Integration Test scripts with

CMS0%

12 System/Integration Testing 0%13 Begin testing 0%14 Gateway returned 0%15 WINet® System Testing 0%16 WINet® system test complete 0%17 Integration Testing Begins 0%18 ATL Test Support 0%19 NG Test Suport 0%20 Nevada Test Support-CMS 0%21 Nevada Test Support - Event 0%22 Intergration Testing Complete 0%23 End testing 0%24 AS400 Ptec 0%25 PVCS 0%26 Write Certification Documents 0%27 Regression Testing28 See scripts in Test Director29 Rollout 0%30 Engineeringrollout support 0%31 Memphis 0%32 1st Gateway (Mem) 0%33 GADAMS 0%34 PDB/Security Box 0%35 2nd Gateway ME2) 0%36 devpdb (24 hour outage) 0%37 Brand MWB/Test Server 0%38 3rd Gateway (PDB) 0%39 prodpdb (24 hour outage) 0%40 MWB/Bus. Obj. 0%41 Las Vegas 0%42 3 Gateways (Will use sre) 0%43 Atlantic City 0%44 1 Gateway (Use AIX 5.2

UPGRADE box as a sre)0%

The testing will generally follow this plan:

1. Set up test directories (that will store scripts, results, expected results for executing various system test conditions along with data) on Test Director

2. Create test driver program(s) (part of test directories set up in #1) on Test Director3. Create (heidev?) database (may not need this – will examine further)5. Create PAMS messages for input along with expected results

- 63 -



6. Create a shell script(s) that executes all test cycles (loads data, runs PAMS messages, unloads data, etc.) – may be part of #2 above

7. Create (if needed) TOP END functionality such as a recoverable transaction queue (RTQ) or a subordinate dialogue (a.k.a Client Server Interaction, CSI, or calling out to a module in another service provider/executable)

8. Document test plans as individual test scenarios (i.e. individual scripts) in as much detail as possible including with all steps, data, results, environments, etc. in Test Director in order to automate, standardize and fully control testing

9. Document procedures to load WINet® on a tape silo (if this is required – may not be necessary)10. Document test data, what it is, etc. (either in Excel or Access or Test Directory—probably all in Test

Director in the end)11. Install all new hardware/software & verify correct operation (in a separate test environment)12. Test all functions by executing test scripts (whether auto or manual) - this is for installation testing,

modules testing, business rules testing, etc. In reality, these will be various cycles of testing and “entity life cycle” tests

13. Record all tests results; note impact on PDB software "as is" and as “expected”14. Test all gateways15. Test volume/load conditions16. Write/execute certification documents17. Rollout live system

- 64 -



System Testing (a.k.a. Testing Part 1)

1. Create the unit testing directory structure within a working directory called “testing”. This directory should contain subdirectories for each testing cycle. Each cycle tests a specific area of the module and is equivalent to a test run in which multiple test conditions are executed. The following is a list of the expected cycles and their purpose:/working_directory/testing/cycle1 - executes test conditions for the initialization sections of the module/working_directory/testing/cycle2 - executes test conditions for the normal processing sections of the module/working_directory/testing/cycle3 - executes test conditions for the error processing sections of the module/working_directory/testing/cycle4 - executes test conditions for database connection error handling

Within each of the cycle subdirectories, there should be directories for input data, expected results, and actual results. These directories are named as follows: .../cycle1/indata contains test data to be loaded into database and input messages.../cycle1/expdata contains expected results in the same format as data in the actdata directory.../cycle1/actdata contains data unloaded from the database after the cycle is executed

2. Within the testing directory, create a test driver program for the module. This can be done by using the template from /work/src/template or by copying an existing test driver program. This test driver program can then be modified as needed. Again, be careful using an existing test driver program as it can lead to “cut and paste” errors.

3. Within the testing directory, create a Makefile to compile the test program. This can be done by using the template from /work/src/template or by copying an existing test driver program Makefile.

4. To begin testing, obtain a heidev database by modifying the file /home/heidev/db_usage on newdev. If all databases are taken, determine which database has testing that is least likely to clash with the testing of the new module then speak with the owner of that database in an attempt to share.

5. For each test cycle, create PAMS messages and input data in each test cycle’s indata directory. For each test cycle, create expected output in each test cycle’s expdata directory.

6. Within the testing directory, create a single shell script that executes all test cycles. For each testing cycle, this script should implement the following logic:

Load the test database with test data from the test cycle’s indata directory Run the SPF test driver using the PAMS messages from the test cycle’s indata directory Unload the pertinent data from the database into the test cycle’s actdata directory. If Fish files were not created in the test cycle’s

actdata directory, move them to this directory.

7. For each test cycle, compare the files within the expdata and actdata directories. If there are discrepancies, adjust the inputs and expdata then re-test.

8. Execute steps 5 through 8 as needed.9. In some scenarios, the unit test cases and system test cases may be one in the same. Occasionally, there are

system test cases that require TOP END functionality such as a recoverable transaction queue (RTQ) or a subordinate dialogue (a.k.a client server interaction, CSI, a.k.a. calling out to a module in another service provider/executable). From this point forward, “system test cases” will refer to both the unit test cases and any additional system test cases unless otherwise stated. The system test cases are executed by sending PAMS messages using a utility called “temsg”. See the temsg usage message for information about its command line parameters. Execute all system test cases with the module running in its service provider under TOP END, i.e. start the service provider. Save the output from the tests for use in the documentation phase.

Details of PDB AIX 5.2 UPGRADE project plan by task

Assessment

All WINet® code will be thoroughly tested for any related changes that will have to be made to make WINet® AIX 5.2 Upgrade compliant.

Write Test Plans

- 65 -



Test plans and scenarios will be written to cover the WINet® system, integration and regression testing. These plans are to be kept on file when testing is complete as part of the certification process. The plans will be in a format that is consistent across all of IT.

Write WINet® load document

This is documentation of the procedures to load WINet® on the new hardware. This will be an internal document to help minimize the errors in the set up of the system. This will cover all information pertaining to the set up of the WINet® Topend node, the batch process, the online processes and any underlying environment options that need to be set.

Create Test Data

Creation of test data to be used in system testing. Also, tools will be used to reset the database so the data can be used again.

Receive Hardware)

The AIX 5.2 UPGRADE machine must be received before any testing can take place.

Hardware Install

Engineering will be receiving the tape silo and the computer attached. Engineering will set the hardware up and install the needed software to make sure this functions as a backup. Once they are confident that the tape silo works this way, then engineering will install the upgraded versions of AIX 5.2 and AIX 5.2 certified Topend. After this is complete, an archive of the WINet® patron database will be migrated to the machine. Engineering will verify that Informix is running properly and accessing the database properly. At this point, the WINet® system can be loaded. The load of WINet® will be achieved through cooperation of engineering and the WINet® development staff.

Load WINet® on AIX 5.2 UPGRADE machine (ID 9)

This is the actual process of loading WINet® on the tape silo. ??????? will be involved with this load.

Unit Test O/S, Informix, Topend (ID 10)

This time will be used to verify that the WINet® system will run on the upgraded version of AIX 5.2. If any upgrade specific problems arise, this time will be used to correct them. WINet® must be up and fully functional before system test and integration testing can begin.

Software changes (ID 11)

NAME ANY PROGRAMS THAT WILL BE CHANGED HERE – NOT KNOW WHICH MAY BE IMPACTED AT THI STIME. About xx other programs will be modified at this time.

Integration Test Scripts with CMS, LMS and EMS (ID 12)

Coordination with CMS, LMS and EMS on what data is being used for integration testing. CMS, LMS and EMS will provide information on what data will be sent to WINet® during testing. WINet® will provide to CMS, LMS and EMS information on what will be sent in the guest synchronization file after completion of posting extract files. The information in the guest synchronization file is directly related to the data that will be sent from CMS, LMS and EMS.

System/Integration Testing (ID 13)

Gateway ????? (ID 15)

The test WINet® gateway is ??????????????????.

WINet® System Testing (ID 16)

- 66 -



This will be a full system test of the WINet® system. This will include batch processing, guest recognition, offer processing and reporting. The system test is being done to prove WINet® ® will work with the new upgraded versions of AIX 5.2, Informix (which version?) and Topend and to prove the upgrades are not effecting other parts of the system. It was originally planned to test each of these things separately. But the decision was made to combine the tests in order to meet the 12/04 deadline.

As it stands, there is very little room for problems. If they do arise, we will have to extend the number of people working on testing and the number of hours worked in order to keep the 12/04 deadline. It is assumed that there will be an engineering resource available if needed.

Integration testing with CMS, LMS, and EMS (ID 17 ID 18 ID 19 ID 20)(ATL Test Support, NG Test Support, Nevada Test Support – LMS, Nevada Test Support – EMS)

This is the integration testing with the external systems that interact with WINet®. We will be testing 3? days: DATE, DATE and DATE. There will be roll over trips included in the DATE data. These trips will start in DATE and continue into DATE. We will receive files from CMS, LMS and EMS. These files will be processed in an environment simulating normal daily extract processing. After the files have been processed, the data will be verified with the guest recognition. This will insure integration testing of guest recognition.

Volume Testing (ID 21)

This time will be used to run at least one full day’s worth of extracts (from all properties) to ensure that nothing is broken.

AS400 Ptec (ID 23)

??????? will assess the Ptec code to make sure there are no changes that need to be made. This is a final check.

PVCS (ID 24)

??????? will system test the new version of PVCS to verify that we will maintain our source code control.

Write Certification Documentation (ID 25)

The required documentation needed to prove that WINet® is AIX 5.2 Upgrade compliant will be written at this time.

Rollout (ID 26)

Engineering will be upgrading prodpdb, devpdb and the Unix gateways with the upgraded versions on AIX 5.2, Informix and Topend. Any code changes that have been made pertaining to these upgrades will be loaded into Projection WINet® also. This is a very tight schedule to perform these upgrades and will require the cooperation of the properties. It was unavoidable that the rollout of these upgrades falls into the December time frame.

- 67 -



- 68 -

End of this document