Casino Blackjack (Group 53)

System Test Plan

Version 1

Revision History

Date | Version | Description | Author
11/05/03 | v1 | Created HTML document & made a start on section 5 | Andrew Noske
27/05/03 | v1 | Updated and reviewed | Andrew Noske and Paul Stasuik

NOTE: Some sections that were not required (accoring to Dmitry's example) were attempted anyway.

Table of Contents

- 1. Introduction
- 2. Evaluation Mission and Test Motivation
- 3. Target Test Items
- 4. Outline of Planned Tests
- 5. Test Approach
  - 5.1 Initial Test-Idea Catalogs and Other Reference Sources
  - 5.2 Testing Techniques and Types
    - 5.2.1 Data and Database Integrity Testing
    - 5.2.2 Function Testing
    - 5.2.3 Business Cycle Testing
    - 5.2.4 User Interface Testing
    - 5.2.5 Performance Profiling
    - 5.2.6 Load Testing
    - 5.2.7 Stress Testing
    - 5.2.8 Volume Testing
    - 5.2.9 Security and Access Control Testing
    - 5.2.10 Failover and Recovery Testing
    - 5.2.11 Configuration Testing
    - 5.2.12 Installation Testing
- 6. Entry and Exit Criteria
- 7. Deliverables
- 8. Testing Workflow
- 9. Environmental Needs
  - 9.1 Base System Hardware
  - 9.2 Base Software Elements in the Test Environment
  - 9.3 Productivity and Support Tools
  - 9.4 Test Environment Configurations
- 10. Responsibilities, Staffing and Training Needs
- 11. Iteration Milestones
- 12. Risks, Dependencies, Assumptions and Constraints
- 13. Management Process and Procedures

System Test Plan

# 1. Introduction

- NOT REQUIRED

## 1.1 Purpose

- Before Casino Blackjack can be released, it must pass a series of tests. These tests are specifically designed to discover errors or bugs, which may have been over-looked during the design and implementation stages. Testing is essential to determining whether the system meets the SRS and is of an acceptable quality for end users.
- The team estimates that complete testing should take an entire week (or more), but due to an optomistic schedule we won't have that long.

## 1.2 Scope

- NOT REQUIRED

## 1.3 Intended Audience

- This Test Plan document is intended for the project's developers, in-house testers and clients. It is by no means intended for end-users.

## 1.4 Document Terminology and Acronyms

- N/A

## 1.5 References

- NOT REQUIRED

# 2. Evaluation Mission and Test Motivation

- NOT REQUIRED

## 2.1 Background

- See project SRS v3.

## 2.2 Evaluation Mission

- Find as many bugs as possible
- Find inportant problems
- Assess project risks
- Assess product quality

## 2.3 Test Motivators

- Key elements which motivate this testing effort include:
  - Project risks (see risks_v3):
    - Success/effeciency of MySQL database platform (risk#1)
    - Security (risk#5)
  - Performance of client-server architecture over various networks.
  - Overall stability of software.

# 3. Target Test Items

- Refer to system as described by project SRS v3.
- database (mysql)
- client-server architecture
- blackjack game
- database interface

# 4. Outline of Planned Tests

- NOT REQUIRED

## 4.1 Outline of Test Inclusions

- Test that the following components work:
  - User-login
  - Gameplay
  - Game State retrieval from database
  - Chat functionality

## 4.2 Outline of Other Candidates for Potential Inclusion

- Test speed and performance of:
  - Gameplay
  - network loads due to TCP/IP communication
  - Chat functionaliy

## 4.3 Outline of Test Exclusions

- None.

# 5. Test Approach

- In order to confirm that the System is implemented according to the project SRS, all SRS requiremnts are listed below with appropriate testing solutions.

## 5.1 Initial Test-Idea Catalogs and Other Reference Sources

- NOT REQUIRED

## 5.2 Testing Techniques and Types

### 5.2.1 Data and Database Integrity Testing

Technique Objective: | To confirm the integrity of the MySQL database which the server-side application will rely on to store critical game and player (login) information.
Technique: | Systematically test that all desired MySQL statements produce desired results. This can then be implemented within the (server-side) java applciaiton.
Oracles: | Write sample database including several players and serveral games. Use thse demonstration tables to check database behaves as expected and produces expected output.
Required Tools: | Requires MySQL to be installed on testing platform.
Success Criteria: | User can create new player in database (if unique username & valid password entered). User can log on from database (if existing username & cooresponding password entered) Player's bankroll is always kept current in database (client always sees correct bankroll). Game can be recreated from database after server crashes.
Special Considerations: | Testing will require correctly set up MySQL database and user priviledges.

### 5.2.2 Function Testing

- NOTE: all testing phases below require the server-side application to be running on a fixed workstation, and at least one client-side application running on the same network (preferably a different workstation). The client should therefore be able to find the server, and the two will connect via sockets and exchange information.

SRS requirement | Test | Successully tested
Test client-server connection:
Client-side applicaiton finds server-side application. | Start execution of client-side application, but don't have server-side application running. System should: display error that says "blackjack server could not be found". Start execution of client-side application and make sure server-side application is also running (on the same network). System should: automatically show the Login screen. | 27April03 on home network
Test user login functionality:
3.1.1) User creates a new virtual player | Click "create new player" in Login screen. Enter valid user name and password (check first user name does not exist in database) in Create new player screen, (e.g. "jon_1234" and "mypassword"). System should: say "player created successfully" & log user into Virtual Casino screen. Clieck "create new player" in Login screen. Enter invalid user/password in Create new player screen. System should: display error & user can try again | superseeded
3.1.2.1) - User logs into virtual casino | Enter valid user name and password (already in database) in Login screen, (e.g: "jon_1234" and "mypassword"). System should: log user into Virtual Casino screen. Enter invalid user/password. System should: display appropriate error & user can try again. | 27April03 on home network
3.1.2.2) - User gets assigned to a table | Click "automatically assign to table" in Virtual Casino screen. System should: eventually find (or create) a table with vacant boxes. User should then see gameplay screen. | 27April03 on home network
Test client-server connection: NOTE: Most of the phases below will require at least two people logged into the same blackjack game. The more people connected to the server & logged into different games the more thorough the testing. After a certain point (say nine players on three different tables) one would assume the system should work for any number number of players and table threads, therefore benchmarking could begin.
3.1.3.1) User can enter bet | Enter & submit bet before timer expirers. System should: not allow you to enter ouside of min & max bets for the table. New table bet & bankroll should update. Don't submit bet before timer expirers. System should: automatically submit whatever bet was entered. | 27April03 on home network
3.1.3.2) Inital cards delt | System should: deal out initial cards automatically (according to rules). Ideally this should give the seemless impression of one card being deal at at time (but very quickly). | Not yet testet
3.1.3.3) Player takes turns. | In subsequence rounds, test each of the following options. hit stay split double insurance System should: only present these options when then apply to the hand. do the correct thing according to the rules after an option is chosen. move onto the next player (in a clockwise direction) after user's first hand has gone bust. NOTE: testing that the players turns work correctly will be the most involved of all test. This testing module will be made time consuming by the statisitical fact that, it may take quite a few rounds before the user is presented with the option to split or pay insurance. QUESTION: Hey Paul - do you think we should break this up into 5 parts - 1 for each user decision (hit etc)? | Not yet tested
3.1.3.4) Dealer takes its turn | System should: show dealer taking his turns (one at a time) according to the rules (ie: dealer hits on 16 or less & stays on anything higher). | Not yet tested
3.1.3.5) Outcome of the game calculated. 3.1.3.6) All cards removed & next round starts. | Make sure correct payments (into players bankroll) are made on all bets (see rules). The system should then clear the table instantly & begin a new round. | Not yet tested
3.1.3.7) At any time a player can hit "leave table". | Click "leave table" at various stages of the game - at least once during the 6 stages illustrated above (3.1.3.1-3.1.3.5). System should: remove any money you've bet on the current round (unless it's the betting phase and you haven't submitted a bet) and store your bankroll securely. If you then join another game you're bankroll is the same as it was from the last round. | Not yet tested
Test in-game chat feature: NOTE: should require at least two people logged into the same game.
3.1.4.1.1) Test chat feature. | Type & submit messages into the chat text box (during various phases of the game). System should: display this message to all players almost immediately. | 23April03 on home network
3.1.4.2.2) Send a private message to a player. | Select a players name on the list and click "send private message". System should: display message to that player only (in the messages window) & clearly show that it's a private message from you. | 23April03 on home network

### 5.2.3 Business Cycle Testing

SRS requirement | Test | Successully tested
NOTE: for installation information see Stage Two.
Check persistance of bankroll:
3.1.3.5) Outcome of the game calculated. | Play a few rounds of game and check bankroll changes accroding to rules. Log out, then log back in again to check that bankroll persists. | Not yet tested

### 5.2.4 User Interface Testing

- Refer to Functionality Testing
- Also:

SRS requirement | Test | Successully tested
NOTE: for installation information see Stage Two.
Check menu bar items:
Check menu items | Test each menu item in sequence for desired result: File >> Exit - closes application Help >> Rules - dialog box appears with link to rules Help >> Help - dialog appears Help >> About - dialog appears & shows credits. | Not yet officially tested

### 5.2.5 Performance Profiling

SRS requirement | Test | Successully tested
NOTE: for installation information see Stage Two.
Test network bandwidth:
Test netwokring bandwidth when sending table object. | Use ethreal to test network load due to TCP IP traffic generated on network. | 27April03 on manning - determined reduced polling to every half second to reduce network load.

### 5.2.6 Load Testing

SRS requirement | Test | Successully tested
Test game performance:
3.3.2.5) The server should be benchmarked to determine maximum number of table threads it can handle gracefully. | Install and run server application. Start client blackjack application on networked computers, connect to server and join a table. Monitor the server's performance as each new client is added until performance is unbearably slow | Not yet tested

### 5.2.7 Stress Testing

- Refer to Load Testing. Closly watch database bandwidth and database locks.

### 5.2.8 Volume Testing

- Refer to Load Testing. This test can determine the maximum load our server can cope with on a given network.

### 5.2.9 Security and Access Control Testing

- Note: the prime concern as far as the security is concerned is denail of service attack. Since none of this money is real - since Casino Blackjack is just a game, if somebody is change his own bankroll, the affects aren't catostropic.

SRS requirement | Test | Successully tested
Test login:
3.1.2.1.1) The playerID and password must be valid. | Try to login as another player using an correct ID, but an incorrect password. | 27April03 on home network
3.3.1.3) Log-in data security to ensure maximum reliability. | Try an method available to hack into blackjack database and instigate a denial of service attack. | Not yet tested
3.3.1.4) Prevent more than one client application from running on a single computer. | Try running more than one client blackjack application on a single computer. Running more than one client per computer should be disabled to prevent one person from playing all player at a particular player. | 19April03 on home network
Test adminstrator adding new payer. | See unit database testing | Not yet tested

### 5.2.10 Failover and Recovery Testing

SRS requirement | Test | Successully tested
Test server recovery:
3.3.2.1) If the client-server crashes, the database should rebuild the game state to before the crash. | Pull the network plug out on the server while a game is underway, and check that the gamestate is reconstructed to it's last saved state. | partly tested on 27April03 on home network

###
5.2.11 Configuration Testing

SRS requirement | Test | Successully tested
Test configuration information:
3.6.8) Provide a config file in XML format that stores the current System configuration (on the server). | See unit testing | 27April03 on home network

### 5.2.12 Installation Testing

- for installation information see Stage Two.

#

# 6. Entry and Exit Criteria

- NOT REQUIRED

#

# 7. Deliverables

- NOT REQUIRED

## 7.1 Test Evaluation Summaries

- Summaries of testing will be appended to this document in HTML form and shown to the client.
- During beta testing, a special testing form will be given to end-users and entered into a database. This form will allow user to:
  - Rate aspects of the software form 1-5.
  - Write a detailed descripton of any bugs or problems they encountered.
  - Include suggestions.
- These results will then be summaried, and the project team will use this information to improve the software for furture releases.

## 7.2 Reporting on Test Coverage

- NOT REQUIRED

## 7.3 Perceived Quality Reports

- NOT REQUIRED

## 7.4 Incident Logs and Change Requests

- NOT REQUIRED

## 7.5 Smoke Test Suite and Supporting Test Scripts

- NOT REQUIRED

## 7.6 Additional Work Products

- NOT REQUIRED

### 7.6.1 Detailed Test Results

- NOT REQUIRED

### 7.6.2 Additional Automated Functional Test Scripts

- NOT REQUIRED

### 7.6.3 Test Guidelines

- NOT REQUIRED

### 7.6.4 Traceability Matrices

- NOT REQUIRED

#

# 8. Testing Workflow

- NOT REQUIRED

#

# 9. Environmental Needs

##
9.1 Base System Hardware

The following table sets forth the system resources for the test effort presented in this Test Plan.

Resource | Quantity | Name and Type
Network or Subnet Server Name Database Name | 1 | jcu.edu.au network
localhost | localhost that the program is installed on (localhost unless machine is uniquely named)
mysql | mysql version 3.23.51.NT or later
Client Test PCs Include special configuration requirements | 4 | pentimum4, 2Ghz, with 512RAM using window XP operating system
configuration files are located in the .bat files and clients are assigned unique ID numbers to ensure sale of product | Virtual Casino client architecture
Network or Subnet Server Name | 1 | jcu.edu.au network
localhost | localhost that the program is installed on (localhost unless machine is uniquely named)
Test Development PCs | pentimum4, 2Ghz, with 512RAM using window XP operating system | home computer

## 9.2 Base Software Elements in the Test Environment

The following base software elements are required in the test environment for this Test Plan.

Software Element Name | Version | Type and Other Notes
NT Workstation | 2000 | Operating System
Windows XP | professional with service packs 1 and 2 installed with critical updates | Operating System
Internet Explorer, or Netscape Navigator | v4+ | Internet Browser NOTE: used to view this site.
Blue jay | v1.4 | Java development platform
MySQL | 3.23.51.NT or later | DBMS
Microsoft Outlook | v6 | Email Client software used to communicate with group members NOTE: used to communicated problems
JBuilder | 8 personal | Java development platform
AVG virus software | v1.6 | Virus Detection and Recovery software used to filter emails

## 9.3 Productivity and Support Tools

The following will be employed to support the test process for this Test Plan.

Tool Category or Type | Tool Brand Name | Vendor or In-house | Version
Test Management | Complete system analysis | In house (Jon) | 1.0
Defect Tracking | Complete system analysis | In house (Jon) | 1.0
Project Management | Microsoft project | Microsoft | XP
DBMS tools | SQLYog | Webyog | 1.7.1

## 9.4 Test Environment Configurations

The following Test Environment Configurations need to be provided and supported for this project.

Configuration Name | Description | Implemented in Physical Configuration
Average user configuration | automated | batch file and java application upon installation
Minimal configuration supported | 500MHz, 512MB RAM computer | N/A
Network installation (not client) | automated | done by installation of executables

# 10. Responsibilities, Staffing, and Training Needs

- NOT REQUIRED

# 11. Iteration Milestones

- NOT REQUIRED

#

# 12. Risks, Dependencies, Assumptions, and Constraints

- NOT REQUIRED

#

# 13. Management Process and Procedures

- NOT REQUIRED