System Test Plan.docx

System Test Plan

Page 1

Department of Computer Science and Engineering

University of Texas at Arlington

Breaking Bat

System Test Plan

Virtual Slugger

Members

Sean Gibeault

Geoff Graham

Ehidiamen Ojielu

Brandon Auwaerter

Roshan Lamichhane

Last updated: 10/10/2014

System Test Plan

Page 2

REVISION HISTORY 5

LIST OF TABLES 6

LIST OF FIGURES 8

1. INTRODUCTION 9

1.1 DOCUMENT OVERVIEW 9

1.2 PRODUCT CONCEPT 9

1.2 PRODUCT SCOPE 10

2. REFERENCES 11

2.1 OVERVIEW 11

2.2 SYSTEM REQUIREMENTS SPECIFICATION 12

2.2.1 CUSTOMER REQUIREMENTS 12

2.2.2 PACKAGING REQUIREMENTS 14

2.2.3 PERFORMANCE REQUIREMENTS 15

2.2.4 SAFETY REQUIREMENTS 15

2.2.5 MAINTENANCE AND SUPPORT REQUIREMENTS 16

2.3 ARCHITECTURE DESIGN SPECIFICATION 17

2.3.1 INPUT LAYER DEFINITION 17

2.3.2 PROCESSING LAYER DEFINITION 17

2.3.3 CONTENT LAYER DEFINITION 18

2.3.4 DATA FLOW DEFINITION 18

TABLE 2-6 - DATA FLOW DEFINITION 19

2.4 DETAILED DESIGN SPECIFICATION 20

2.4.1 DETAILED DESIGN DIAGRAM 20

2.4.2 PRODUCER-CONSUMER MATRIX 21

2.4.3 REQUIREMENTS TRACEABILITY MATRIX 21

3. TEST ITEMS 26

3.1 OVERVIEW 26

3.3 HARDWARE TESTS 28

System Test Plan

Page 3

3.4 UNIT TESTS 29

3.4.1 INPUT TESTS 29

3.4.2 PROCESSING TESTS 30

3.4.3 CONTENT TESTS 33

3.5 COMPONENT TESTS 34

3.6 INTEGRATION TESTS 36

3.7 SYSTEM VERIFICATION TESTS 37

4 RISKS 38

4.1 OVERVIEW 38

4.2 TABLE OF RISKS 38

5. FEATURES TO BE TESTED 39

5.1.1 SWITCH HITTING CAPABILITY 39

5.1.2 SETTING CONFIGURATION 39

5.1.3 HIT VIRTUAL BASEBALL 39

5.1.4 REAL WORLD BAT 40

5.1.5 VIRTUAL REALITY BATTING ENVIRONMENT 40

5.1.6 FEEDBACK 40

5.1.7 REAL TIME STATISTICS 40

5.1.8 SWITCH PITCHING 41

5.1.9 MODE SELECTION 41

5.1.10 LEARN FUNDAMENTALS OF BASEBALL 41

5.2.1 VIRTUAL REALITY DEVICE 41

5.2.2 XBOX CONTROLLER 42

5.2.3 SENSORS 42

5.2.4 SOFTWARE 42

5.2.5 COMPUTER 42

5.3.1 SIMULATOR SICKNESS 42

5.4.1 SOURCE CODE DOCUMENTATION 43

5.4.2 TROUBLESHOOTING GUIDE 43

5.5.1 LATENCY 43

5.5.2 GRAPHICS 43

5.6.1 USER FRIENDLY INTERFACE 44

6. FEATURES NOT TO BE TESTED 46

System Test Plan

Page 4

6.1.1 PHYSICAL BASEBALL BAT 46

6.2.1 BASEBALL BAT HAZARD 46

6.2.2 MENTAL HEALTH 46

6.3.1 HARDWARE SUPPORT 47

6.3.2 SOFTWARE SUPPORT 47

6.4.1 AMERICAN ENGLISH STANDARD 47

7. OVERALL TEST STRATEGY 49

7.1 OVERVIEW 49

7.2 STRATEGY 49

7.3 TESTING METRICS 49

8. CRITERIA SPECIFICATION 50

8.1 OVERVIEW 50

8.2 ACCEPTANCE CRITERIA 50

8.2.1 HARDWARE TESTING 50

8.2.2 MODULE TESTING 51

8.2.3 COMPONENT TESTING 52

8.2.4 LAYER INTEGRATION TESTING 53

8.2.5 SYSTEM TESTING 54

8.3 SUSPENSION AND RESUMPTION CRITERIA 55

8.3.1 SUSPENSION CRITERIA 55

8.3.2 RESUMPTION CRITERIA 55

9. TEST DELIVERABLES 57

9.1 OVERVIEW 57

9.2 DELIVERABLES 57

9.2.1 SYSTEM TEST PLAN 57

9.2.2 TEST CASE SPECIFICATIONS 57

9.2.3 TEST CASE RESULTS 57

9.2.4 BUGS AND DEFECTS 58

10. TEST SCHEDULE 59

11. APPROVALS 59

System Test Plan

Page 5

Revision History

Revision

Number Revision Date Description Rationale

0.1 10/08/2014 Test Plan First Draft First Draft

1.0 10/10/2014 System Test Plan Review Version Initial offering of STP

System Test Plan

Page 6

List of Tables

Table # Title Page #

2-1 Customer Requirements 15

2-2 Packaging Requirements 16

2-3 Performance Requirements 17

2-4 Safety Requirements 17

2-5 Maintenance and Support Requirements 18

2-6 Data Flow Definition 20

2-7 Input Requirement Traceability 24

2-8 Processing Requirement Traceability 26

2-9 Content Requirement Traceability 27

3-1 Hardware Test 31

3-2 Input Tests 32

3-3 Processing Tests 34

3-4 Content Tests 35

3-5 Component Tests 36

3-6 System Verification Tests 39

4-1 Risks 40

5-1 Requirements 46

6-1 Other Requirements 49

8-1 Hardware Testing Criteria 52

8-2 Module Testing Criteria 53

8-3 Component Testing Criteria 55

8-4 Layer Integration Testing Criteria 56

8-5 System Testing Integration Criteria 56

8-6 Suspension Criteria 57

System Test Plan

Page 7

8-7 Resumption Criteria 57

10-1 Test Schedule 61

11-1 Approvals 61

System Test Plan

Page 8

List of Figures

Figure # Title Page #

2-1 Architecture Design 19

2-2 Detailed Design Diagram 22

2-3 Producer-Consumer Matrix 23

3-1 Relational Diagram 29

System Test Plan

Page 9

1. Introduction

1.1 Document Overview

The System Test Plan is intended to describe in detail how the Virtual Slugger will be tested to

ensure a quality product. The testing plan will be detailed including unit, component, and

integration tests. Testing considerations from previous documents will be included and described

in more detail.

1.2 Product Concept

The Virtual Slugger is virtual batting simulation game that will employ the Oculus Rift virtual

reality device, an Xbox controller, Kinect, and a mini arduino sensor called a femtoduino to

immerse players in a virtual environment where they can practice their batting skills. Players will

be able to set up their configuration to their body specifications, bat length, and skill level of the

player(Little-league - Professional).

The Virtual Slugger will track the user’s stats throughout a session and give the user feedback on

how to improve their skill. The system will display how many hits, home runs, foul balls and

other statistics from the session that a batting instructor could use to help the play improve and

track their development,

The Virtual Slugger will be installed on a PC. The program will be launched from the operating

system and display the main menu. Once the user starts a new game they will chose either

Practice or Home Run Derby and begin batting. The user will say pitch out loud and the kinect

sensor will trigger the pitcher to pitch the ball to the user at a predetermined range of speeds

depending on the difficulty level the user has selected.

The Virtual Slugger’s intended users are all levels of baseball players ranging from amateurs to

professionals. The intended consumer would be aspiring baseball players or professionals that

want to practice their swing. Additional consumers would be baseball teams or organizations

that would like to try new technology to improve batting averages.

System Test Plan

Page 10

1.2 Product Scope

The Virtual Slugger is designed to simulate a real game situation that baseball players will

encounter. The game will be launched from the computer. The user will input which type of

batter they would like to be such as a “dirt bag”, “rabbit” or “bopper”. The user will also be able

to choose which type of pitches they would like to work on or choose a random order of pitches.

Once the game starts the batter will face a virtual pitcher until they either hit the ball or they

strike out. Once there is a break in the game (hit or strikeout) the system will give the user

feedback on their swing and advice on how to improve i.e.: try to hit the ball lower or higher

depending on which type of hitter they have selected.

The hardware component are Oculus Rift that provide virtual reality environment, Xbox

controller and sensor (Femtoduino) for calculating the position and swing speed of the bat. The

user interface will feature Menu for starting game, selecting options and exiting the game.

System Test Plan

Page 11

2. References

2.1 Overview

This section details the references used to develop this test plan. These documents include the

System Requirements Specification, Architecture Design Specification, and the Detailed Design

Specification. These documents provide the requirements, modules, and layers that will need to

be tested.

The architectural design for the Virtual Slugger consists of three layers encapsulated by the

Unreal Game Engine. This means that the structure of our architecture will be relying upon UDK

4 Game Engine to process and display output to the user via the output devices. The layers are

an input layer, processing layer, and content layer. Input will be received from the Oculus Rift,

Xbox controller, Kinect, and Femtoduino. The input layer handles the processing of the inputs

and sends the data through to the processing layer modules. The Processing layer will be

responsible for all the interactions the play has in the game environment. The content layer will

store our assets to be used by the game engine such as static and skeletal meshes or the level

map.

System Test Plan

Page 12

2.2 System Requirements Specification

The SRS details the requirements of the Virtual Slugger. All requirements will be listed here but

they may not actually be testable or require testing.

2.2.1 Customer Requirements

This section covers the requirements that have been established by the customer for the Virtual

Slugger product. It covers each feature and gives a description to establish the “look and feel” as

well as to give an idea of what the end-user should expect the product to do. The requirements

have also been given a priority to give a general idea of how important each feature is to the

Virtual Slugger product.

Number Requirement Description Priority

3.1 Switch Hitting Capability The user will have the option of

choosing to bat left-handed or right-

handed. This will change the view in

the Virtual Slugger system to

accommodate both batting styles.

1

3.2 Settings Configuration Virtual Slugger should allow the user

before batting to configure their

settings such as height of user, speed of

pitches, and type of batter. These

configurations will personalize settings

to determine the user’s strike zone and

help give feedback after batting.

1

3.3 Hit Virtual Baseball Virtual Slugger should allow the user

the ability to see a virtual baseball

(pitch) thrown and allow the user to

swing a real baseball bat to try to

‘make contact’ with the virtual

baseball.

1

3.4 Real World Bat Virtual Slugger should allow the user

to use a real baseball bat in order to

make the batting experience as realistic

as possible.

1

System Test Plan

Page 13

3.5 Virtual Reality Batting

Environment

The Virtual Reality simulator will

display a batting environment in order

to make the batting experience as

realistic as possible.

3

3.6 Feedback The Virtual Slugger should provide

feedback on what to modify in order to

improve their batting following a

batting session. Different feedback will

be delivered based on batting style

chosen along with statistics from the

session. Feedback will be given at the

end of the user’s at bat and will

include, but not be limited to change of

batter’s stance, arch of swing, and head

movement.

1

3.7 Real Time Statistics The Virtual Slugger should gather real-

time statistics during the user’s batting

session. These statistics will be

available for review after each session.

1

3.8 Learn Fundamentals of

Hitting

The user will learn the fundamentals of

Batting via one of three types of

batting style they choose to train for.

These three batting styles consist of a

“bopper” which trains to hit the ball

with power, a “rabbit” which trains to

hit the ball on the ground, and a

“dirtbag”, who hits the ball for line

drives. Based on the batting style

chosen, a summary of the batting style

will be available along with feedback

after batting sessions.

3

3.9 Switch Pitching The Virtual Slugger should provide the

user an option to choose whether the

pitcher is left handed or right handed.

4

3.10 Mode Selection The Virtual Slugger should provide the

user an option to choose which mode

they wish to use. The current modes

will consist of “Practice” and “Home

2

System Test Plan

Page 14

Run Derby”. The Practice mode will

allow the user to bat based on the

batter type chosen to practice as. The

Home Run Derby Mode will allow the

user to have ten ‘outs’ to hit the most

home runs that they can.

Table 2 -1 - Customer Requirements

2.2.2 Packaging Requirements

This section provides information on how the Virtual Slugger will be packaged for the end user.


4.1 Virtual Reality Device The product will include a virtual reality

headset.

1

4.2 Physical Baseball Bat A baseball bat will be provided for the user

to interact with the virtual environment.

2

4.3 X-Box Controller An Xbox controller will be provided for

users to interact with the menus and select

preferences.

3

4.4 Sensors Sensors will be provided with the product

and used with the bat to monitor its motion.

1

4.5 Software Software will be included either as an

installable USB or CD/DVD.

2

4.6 Computer Control computer on which software will

run as shown in Fig 1.1. Recommended

specifications are as follows:

● PC or Mac

● Windows 8 64-bit

● Quad-core Intel or AMD processor,

2.5 GHz or faster

● NVIDIA GeForce 470 GTX or

AMD Radeon 6870 HD series card

or higher

● 8 GB RAM

2

System Test Plan

Page 15

Table 2-2 - Packaging Requirements

2.2.3 Performance Requirements

This section highlights the technical performance requirements of the product.


5.1 Latency Latency is currently an issue with virtual

reality devices. However, the user should

experience as little latency as possible to

ensure accuracy when hitting pitches.

2

5.2 Graphics The user should experience smooth game play,

animations and interactions when using the

Virtual Slugger.

2

Table 2-3 - Performance Requirements

2.2.4 Safety Requirements

This section highlights the safety issues associated with the product with detailed description.


6.1 Simulator Sickness This is similar to motion sickness and

may cause nausea, sweating or vomiting.

The product will help mitigate this by

using correct camera calibration and

distortion. Also, a warning label will

printed on the product to address this

requirement.

1

6.2 Baseball Bat Hazard A warning label will placed on the

product advising users to provide

adequate room when in use due to the

hazards of using a real baseball bat.

1

6.3 Mental Health Hazard A label that warns against excessive use

will be affixed to the Virtual Slugger as

excessive use could affect the health of

the user.

3

System Test Plan

Page 16

Table 2-4 - Safety Requirements

2.2.5 Maintenance and Support Requirements

This section covers maintenance and support for end users after delivery of product.


7.1 Source Code

Documentation

Detailed and clean code must be

provided for future reference,

updates and technical support.

2

7.2 Hardware Support Provide replaceable components for

users if issue is within the scope of

hardware built by the team.

3

7.3 Software Support Bugs reported by users will be

handled by the software team and

marked with the appropriate priority

level.

2

7.4 Troubleshooting Guide A troubleshooting guide will be

provided with the Virtual Slugger.

2

Table 2-5 - Maintenance and Support Requirements

System Test Plan

Page 17

2.3 Architecture Design Specification

Figure 2-1 - Architecture Design

2.3.1 Input Layer Definition

The Input Layer gathers data that comes from the Oculus Rift, Kinect, Xbox controller,

accelerometer and gyroscope. The data collected in the Input Layer is transferred to the

Processing Layer for further processing. Oculus SDK gathers information on head movement,

Xbox controller will work as the button-listener, accelerometer gathers information on the speed

of bat swing, and gyroscope gathers information on orientation of bat.

2.3.2 Processing Layer Definition

The Processing Layer is responsible for processing the information gathered through the Oculus

Rift, Kinect, Xbox controller, accelerometer and gyroscope. Processing layer is responsible for

managing all the interactions the player will have within the virtual environment. It consists of

Statistics Analyzer, Player Controller, AI Controller, Game Events, and Game Start subsystems.

System Test Plan

Page 18

2.3.3 Content Layer Definition

The Content Layer is responsible for storing all of the assets needed for the game. It consists of

Level, Audio, Materials and Meshes subsystems. The processing layer will be able to

connect to Content Layer and load level assets, player models, and sounds to be rendered by the

Unreal Engine.

2.3.4 Data Flow Definition

Data Flow Definition

I1 The Plug-in for the Kinect sends user swing data to the Statistics

Analyzer to process the swing and display feedback to the user

I2 The Femtoduino Plug-in sends Acceleration and Orientation Data

to the Player Controller to control the virtual baseball bat

I3 The X-Box Controller Plug-in sends button events and joystick

data to the Game Start sub system to navigate the menu

P1 Game Start sends the type of hitter the user selected to the

Statistics Analyzer so that it can give the user the right type of

feedback

P2 Game Start initializes the AI Controller by setting the difficulty

level (Little League - Professional)

P3 Game Start initializes the Player Controller, sending it the player’s

height and bat length

P4 The Player Controller sends the velocity of the users swing to the

Statistics Analyzer to display on screen

P5 The AI Controller Interacts with the Game Event subsystem

triggering events when the virtual baseball enters certain areas

P6 Game Start Initializes the Game Event subsystems by setting the

players strike zone based off player height

P7 The Player Controller tells the AI Controller when the bat has hit

the ball and sets the hit variable to true

C1 The Materials subsystems applied textures to the Meshes

System Test Plan

Page 19

subsystem

C2 The Meshes subsystem loads its bat and player meshes to the

Player Controller (.fbx format)

C3 The Meshes subsystem loads its pitcher and baseball meshes to the

AI Controller (.fbx format)

C4 The Audio subsystem loads .wav files to the Player Controller

C5 The Audio subsystem loads .wav files to the AIController

C6 The Level subsystems sends its Umap file to the Game Start

subsystem to be loaded

Table 2-6 - Data Flow Definition

System Test Plan

Page 20

2.4 Detailed Design Specification The detailed architecture design for the Virtual Slugger is made up of three key layers which consist of

the Input Layer, Processing Layer, and Content Layer. These layers together represent the unreal engine

in which we will be developing our project on.

2.4.1 Detailed Design Diagram

Figure 2-2 - Detailed Design Diagram

System Test Plan

Page 21

2.4.2 Producer-Consumer Matrix

Figure 2-3 - Producer-Consumer Matrix

2.4.3 Requirements Traceability Matrix

Input Layer Traceability

System Test Plan

Page 22

Req No Requirement

Name

Xbox

Plugin

Kinect Plugin Oculus Rift

Plugin

Femtoduino

Plugin

3.1 Switch Hitting

Capability

X

3.2 Setting

Configuration

X

3.3 Hit Virtual Baseball X X

3.4 Real World Bat X

3.5 Virtual Reality

Batting

Environment

X

3.6 Feedback X

3.7 Real Time Statistics X X

3.8 Learn

Fundamentals of

Hitting

X

3.9 Switch Pitching X

3.10 Mode Selection X

4.1 Virtual Reality

Device

X

4.2 Physical Baseball

Bat

4.3 Xbox Controller X

4.4 Sensors X

5.1 Latency X X

6.1 Simulator Sickness X

8.1 American English

Table 2-7 - Input Requirement Traceability

System Test Plan

Page 23

Processing Layer Traceability

Req No Requirement

Name Menu Initializer HUD

Collis

ion

Boxes

Base

ball

Bat

Cha

ract

er

Pitc

her

Baseb

all

3.1 Switch Hitting

Capability

X X X

3.2 Setting

Configuration

X X

3.3 Hit Virtual

Baseball

X X X X

3.4 Real World Bat X

3.5 Virtual Reality

Batting

Environment

3.6 Feedback X X X

3.7 Real Time

Statistics

X

3.8 Learn

Fundamentals

of Hitting

X

3.9 Switch Pitching X X X

3.10 Mode Selection X X

System Test Plan

Page 24

4.1 Virtual Reality

Device

X

4.2 Physical

Baseball Bat

X

4.3 Xbox

Controller

X

4.4 Sensors X

5.1 Latency X

6.1 Simulator

Sickness

8.1 American

English

Table 2-8 - Processing Requirement Traceability

7.3 Content Layer Traceability

Req No Requirement

Name

Map Textures Static Skeletal Sounds

3.1 Switch Hitting

Capability

X X

3.2 Setting

Configuration

X X X X

3.3 Hit Virtual

Baseball

X X X

3.4 Real World Bat X X X

3.5 Virtual Reality

Batting

Environment

X X

3.6 Feedback

3.7 Real Time

Statistics

3.8 Learn

Fundamentals of

System Test Plan

Page 25

Hitting

3.9 Switch Pitching X X

3.10 Mode Selection

4.1 Virtual Reality

Device

4.2 Physical Baseball

Bat

4.3 Xbox Controller

4.4 Sensors

5.1 Latency

6.1 Simulator

Sickness

8.1 American

English

Table 2-9 - Content Requirement Traceability

System Test Plan

Page 26

3. Test Items

3.1 Overview

Team Breaking Bat will first test each module and ensure that it is functioning properly. Since there is no

unit testing in Unreal Engine, we must test this functionality through visual inspections during game play.

Team Breaking Bat will set up specific situations that will isolate certain modules so we can test a

module's functionality at the most basic level. After all modules for a particular component have passed

we then move on to component testing. This will include sending input/output from one module to

another inside the same component. Then once all the component test have passed we can move on to

integration testing and finally system testing. Team Breaking Bat expects to run numerous visual

inspection test to verify all functionality is working as it should.

System Test Plan

Page 27

3.2 Relational Diagram

Figure 3-1 - Relational Diagram

System Test Plan

Page 28

3.3 Hardware Tests

Test ID Hardware

Component

Input Expected

Output/

Action

Test Risk

H1 Femtoduino voltage to

power

accelerometer

and

gyroscope

sensors

x, y, z

acceleration

and

gyroscope

data stream

Use a 3D

processing

arduino

sketch that

verifies that

accelerometer

and

gyroscope

data are being

sent correctly

1-Critical

H2 Oculus Rift video stream

from game

application

x,y,z

acceleration

and

gyroscope

data for head

tracking as

well a 3D

representation

of the video

stream being

supplied

during

gameplay

visually

inspect the

game with the

headset on

1-Critical

H3 Kinect 2.0 3D depth

camera video

stream and

microphone

connected via

USB

bone

structure and

position in

3D space, and

audio stream

test that when

the user says

“pitch” that it

is properly

accepted by

the Kinect

plugin

1-Critical

H4 X-Box 360

Wireless

Controller

power

supplied to

the controller

and OS

stick and

button press

events

during

gameplay test

each

movement

1-Critical

System Test Plan

Page 29

recognition of

device

individually

and visual

inspect if that

was the

correct action

H5 Speakers .wav files

supplied by

the sound

module

play sound Manual

Inspection

2-High

H6 Monitor video stream

from game

application

images during

gameplay

visually

inspect the

monitor in

which the

game will be

displayed on

2-High

Table 3-1 - Hardware Test

3.4 Unit Tests

3.4.1 Input Tests

Test ID Unit/

Module

Input Expected

Output/

Action

Test Risk

UI1 Femtoduino

Plugin

x,y, and z

values for

accelerations

and

gyroscope

calibrated

acceleration

and

gyroscope

data to be

sent to the bat

module

Verified by

printing

values that

are sent to the

screen

1-Critical

UI2 Oculus Rift

Plugin

x, y, and z

values for

accelerations

and

gyroscope

video stream

from game

application

verify by

visual

inspection

during game

play

1-Critical

System Test Plan

Page 30

UI3 Kinect 2.0

Plugin

image and

audio stream

raw audio

data (pulse

code

modulation),

depth and

skeletal data

verify that the

Kinect will

record the

“pitch”

command and

start the pitch

animation

1-Critical

UI4 X-Box 360

Wireless

Controller

Plugin

stick

movement

and button

press events

player

navigation

through

menus are

capable with

the correct

bindings

verify by

pressing keys

and visually

observing a

correct

response

1-Critical

Table 3-2 - Input Tests

3.4.2 Processing Tests

Test ID Unit/Module Input Expected

Output/

Action

Test Risk

UP1 Menu stick and

button press

events

Menu fields

contain the

proper

information

for the

respective

field

Navigate

through the

menu options

with the X-

box controller

and visually

inspect that

the values

chosen are

1-Critical

UP2 Initializer values set by

the user in the

menu

set variables

in the

respective

modules and

load the

baseball map

with the

Print

variables to

screen at each

module to

verify that

correct data is

being passed.

1-Critical

System Test Plan

Page 31

proper game

mode

Also, visual

inspection

that the

baseball

stadium has

been loaded

UP3 HUD ball/strike

data. type of

hitter.

distance ball

traveled.

feedback

strings.

visual

representation

of current

state of

variables

during game

play visually

inspect that

the HUD is

being shown

and that the

data is being

updated at the

correct times

with the

correct data.

1-Critical

UP4 Collision

Boxes

collision

overlap

events

baseball hit

by virtual bat.

baseball hits

virtual

environment.

baseball hits

strike zone

and catcher

collision

boxes.

test each

individual

collision

event and

verify the

correct action

is taken

1-Critical

UP5 Baseball Bat Femtoduino

x,y,z

accelerometer

and

gyroscope

data. collision

events to

register with

baseball and

environment

visual

representation

of the

baseball bat

modeled in

the 3D

environment

and correct

1:1

movement

between the

user moving

the real-bat

and the visual

representation

of the virtual

test that the

virtual

baseball bat’s

variables are

being

correctly set

and visually

inspecting for

latency.

1-Critical

System Test Plan

Page 32

bat

UP6 Character character

height, type

of hitter,

right/left

variables set

by the user in

the menu

options

character

model is

loaded in the

correct

position with

the correct

height with

the baseball

bat in hands

during game

play visually

test that the

character is

loaded

correctly

1-Critical

UP7 Pitcher “pitch”

command

from kinect to

initiate

pitcher

animation

pitcher 3D

model will

perform

pitching

animation

and spawn

the baseball

verify that the

pitch

animation is

being

performed

and that the

pitcher is

spawning the

baseball

1-Critical

UP8 Baseball spawn

baseball

event is fired

when

pitching

animation has

reached a

halfway

point. The

baseball will

also have to

respond to

collision

events.

spawns

baseball with

initial

velocity and

trajectory.

verify that the

baseball is

being

spawned with

the

appropriate

velocity and

trajectory.

Also, verify

that the

baseball is

properly

reacting to

collision

events

1-Critical

Table 3-3 - Processing Tests

System Test Plan

Page 33

3.4.3 Content Tests

Test ID Unit/Module Input Expected

Output/

Action

Test Risk

UC1 Map coordinates

with static

mesh

references

Baseball

Stadium and

Menu are

properly

displayed

During game

play visually

inspect the

stadium and

the menu to

verify they

are displayed

correctly

2-High

UC2 Textures .FBX texture Properly

wraps around

materials

During game

play visually

inspect that

the texture

and verify

that it looks

correct

3-Moderate

UC3 Sounds .wav sound

files

Appropriate

sounds are

played during

game play.

Test specific

situations in

which a

particular

sound should

be played and

verify that it

is correct by

listening to it

3-Moderate

UC4 Static .FBX

Material

Properly

wraps around

static meshes

During game

play visually

inspect the

material to

verify that it

looks correct

2-High

UC5 Skeletal .FBX

Material

Properly

wraps around

character and

pitcher

During game

play visually

inspect both

character and

3-Moderate

System Test Plan

Page 34

wireframes pitcher

models and

verify they

look correct

Table 3-4 - Content Tests

3.5 Component Tests

Test ID Subsystem Input Expected

Output/

Action

Test Risk

CI1 Plug-ins data from

hardware

components

received and

ready to be

transported to

the

subsystems in

the

processing

layer

verify that

plug-in can

receive input

from

hardware

1 - Critical

CP1 Player

Controller

data from

hardware

components

i.e. oculus rift

and

Femtoduino

character and

bat

verify that

character and

bat interact

with inputs

1 - Critical

CP2 Statistics

Analyzer

data from the

plug-in

subsystem

processed

data shown to

the user in the

HUD

when the user

hits a pitch it

should

display

accurate

swing speed

and distance

traveled

1 - Critical

CP3 Game Events collision

events from

objects in the

level

trigger event

in game

each collision

box defined

in the level

should trigger

1 - Critical

System Test Plan

Page 35

the right

response

CP4 Game Start User

configuration

Load game

with

preferred

setting

User

preferred

setting are

reflected in

game load

1- Critical

CP5 AI Controller initiate AI

based events

pitcher

throws

baseball

pitch should

be sent with

the

appropriate

velocity

based on

user’s

configuration

1 - Critical

CC1 Level static mesh

components

a map of

static mesh

components

the requested

level map

should be

rendered

1 - Critical

CC2 Audio wav audio

files

wav audio

files

trigger the

appropriate

audio for hit

event and

swing events

2 - High

CC3 Materials textures to be

applied on

meshes

textures

applied on

meshes

actor and

pawns i.e

objects

should load

with the right

texture

material

3 - Moderate

CC4 Meshes static and

skeletal mesh

components

render static

and skeletal

meshes

all actors and

pawns should

be loaded on

screen

1 - Critical

Table 3-5 - Component Tests

System Test Plan

Page 36

3.6 Integration Tests

Test ID Layers Input Expected

Output/Actions

Test Risk

LI1 Input Input from all

components i.e

Femtoduino,

oculus rift etc.

All input from

the hardware (i.e

xbox, oculus rift,

Femtoduino) are

successfully sent

to the input layer

for transport to

the processing

layer

Moving the

bat and

character in

the game

using the

external

baseball bat

attached to

the

Femtoduino

as a

controller

1 - Critical

LI2 Processing Data from the

input layer

such as game

configuration

and sensor data

The actors and

pawns are

reacting based on

user commands

User is able

to hit a pitch

and show

statistics in

the HUD

1 - Critical

LI3 Content on load Actors have the

appropriate

textures and and

meshes and

actions reference

the right audio

During game

play,

visually

inspect

objects in the

scene and

ensure audio

components

work as well

1 - Critical

System Test Plan

Page 37

3.7 System Verification Tests

Test ID Input Expected Output Test Fail Criteria

SV1 Installer Game installs successfully. perform a clean

installation of

Virtual Slugger

1 - Critical

SV2 Virtual Slugger Game successfully loads the

main menu.

verify the user

can see the menu

1 - Critical

SV3 Virtual Slugger

and Oculus Rift

Game successfully interacts

with the Oculus Rift and

allows the user to see their

head movements in game.

verify that the

character moves

with head

1 - Critical

SV4 Virtual Slugger Game play is suspended

when pause menu is

displayed.

verify that the

menu suspends

the game play

2 - High

SV5 Virtual Slugger Virtual baseball can be ‘hit’

by the bat

verify that the

system detects the

collision

1- Critical

SV6 Virtual Slugger Audio such as crack of bat

hitting baseball works when

cued

verify that audio

files are loaded

with the game

2 - High

SV7 Virtual Slugger Live stats are displayed verify that the

system can

display real time

statistics

1 - Critical

SV8 Virtual Slugger The game provides proper

feedback

verify that hits are

analyzed

accurately by the

system

1 - Critical

Table 3-6 - System Verification Tests

System Test Plan

Page 38

4 Risks

4.1 Overview

This highlights the risks that may affect the testing process and outcome. This section will highlight the

risks impact, severity and management plan.

4.2 Table of Risks Each risk has been assigned a severity rating of high, moderate or low.

Risk Impact Severity Management Plan

Oculus Rift not

functioning

Oculus Rift plugin

testing will be halted

and could affect

delivery of final

product.

High Ensure the Oculus Rift

in proper condition on

arrival.

Xbox controller not

functioning

Xbox controller module

and menu module tests

will be halted.

High Ensure the Xbox

controller is in proper

working condition.

Femtoduino not sending

data over bluetooth

Femtoduino plugin test

will be halted and could

affect the final delivery

of the product.

High Ensure that all sensors

are in good working

condition.

Kinect not functioning Kinect plugin test will

be halted and could

affect the delivery of

the product.

High Ensure that the kinect is

in good working

condition.

Table 4-1 - Risks

System Test Plan

Page 39

5. Features to be Tested

The features to be tested will be based on the requirements in System Specification Requirements. The

requirements will be tested to ensure that Virtual Slugger satisfies the functional and nonfunctional

specifications.

5.1 Customer Requirements

5.1.1 Switch Hitting Capability

Description: The user will have the option of choosing to bat left-handed or right-

handed.

Risk: High

Test Approach: Team Breaking Bat will verify that the Virtual Slugger will be able to

switch the bat side as left handed or right handed.

5.1.2 Setting Configuration

Description: Virtual Slugger should allow the user before batting to configure

their settings such as height of user, speed of pitches, and type of batter. These

configurations will personalize settings to determine the user’s strike zone and

help give feedback after batting.

Risk: Critical

Test Approach: Team Breaking Bat will set the configurations like bat-size, resolution,

pitch speed, pitch side and bat side and test the configuration in-game.

5.1.3 Hit Virtual Baseball

Description: Virtual Slugger should allow the user the ability to see a virtual

baseball (pitch) thrown and allow the user to swing a real baseball bat to try to ‘make

contact’ with the virtual baseball.

Risk: Critical

Test Approach: Team Breaking Bat will swing the real world bat and hit the virtual

baseball and reviews if the baseball was hit by the virtual bat.

System Test Plan

Page 40

5.1.4 Real World Bat

Description: Virtual Slugger should allow the user to use a real baseball bat in order to

make the batting experience as realistic as possible.

Risk: Critical

Test Approach: Team Breaking Bat will make movements with the real world bat and

verify if the movement of the virtual bat matches the movement of the real bat.

5.1.5 Virtual Reality Batting Environment

Description: The Virtual Reality Simulator will display the batting environment in

order to make the batting experience as realistic as possible.

Risk: Critical

Test Approach: Team Breaking Bat initiates the game and verifies if the level loaded is

the virtual environment is the same as the realistic baseball stadium that was loaded from

the map.

5.1.6 Feedback

Description: The Virtual Slugger should provide feedback on what to modify in order

to improve their batting following a batting session based on what type of batter they

want to be.

Risk: Critical

Test Approach: Team Breaking Bat will play the game as “Dirtbag” “Bopper” and

“Rabbit” and for each play after the end of the game the feedback will be generated with

the respective batting style.

5.1.7 Real Time Statistics

Description: Virtual Slugger should gather real-time statistics during the user’s batting

session and display it to the user.

Risk: Critical

Test Approach: Team Breaking Bat will verify if the related information is

continuously displayed on HUD during the batting session.

System Test Plan

Page 41

5.1.8 Switch Pitching

Description: Virtual Slugger should provide the user an option to choose to pitch from

left or right side.

Risk: Low

Test Approach: Team Breaking Bat will set the pitching side to once for right side and

once for left side and verify if the pitches are thrown from the selected side.

5.1.9 Mode Selection

Description: Virtual Slugger should allow the user to select between “Practice” and

“Home Run Derby”.

Risk: High

Test Approach: Team Breaking Bat will select the options of playing as “Practice” and

“Home Run Derby” and verify if the user is able to play for as long as they want as in

“Practice” or the game allows only ten ‘outs’ in “Home Run Derby”.

5.1.10 Learn Fundamentals of Baseball

Description: The user will learn the fundamentals of batting as “Bopper”, “Rabbit” and

“Dirtbag”.

Risk: Moderate

Test Approach: Team Breaking Bat will verify that the Virtual Slugger displays

important statistics and information based on the player type so that the user will

understand the basics of batting and improving their batting style.

5.2 Packaging Requirements

5.2.1 Virtual Reality Device

Description: The product will include virtual reality device.

Risk: Critical

Test Approach: The virtual reality device, in our case, Oculus Rift can be tested with

set of hardware tests.

System Test Plan

Page 42

5.2.2 Xbox Controller

Description: An Xbox Controller will be provided for the users to interact with the

menus and select preferences.

Risk: Moderate

Test Approach: Xbox Controller can be tested with a set of hardware tests.

5.2.3 Sensors

Description: Sensors will be provided with the product and used with the bat to monitor

its motion.

Risk: Critical

Test Approach: Sensors will be tested with a set of hardware tests.

5.2.4 Software

Description: Software will be included as an installable USB or CD/DVD.

Risk: Critical

Test Approach: Software will be tested with validation and integration tests.

5.2.5 Computer

Description: Control computer on which software will run.

Risk: Critical

Test Approach: Game will be played in the specified computer with the specification

provided in the requirements.

5.3 Safety Requirements

5.3.1 Simulator Sickness

Description: This is similar to motion sickness and may cause nausea, sweating or

vomiting. The product will help mitigate this by using correct camera calibration and

distortion. Also, a warning label will printed on the product to address this requirement.

Risk: Critical

System Test Plan

Page 43

Test Approach: Team Breaking Bat will personally test for the simulator sickness by

playing the game for the certain period of time.

5.4 Maintenance and Support Requirements

5.4.1 Source Code Documentation

Description: Detailed and clean code must be provided for future reference,

updates and technical support.

Risk: High

Test Approach: Rigorous code reviews will be conducted to ensure the consistency and

readable code.

5.4.2 Troubleshooting Guide

Description: A troubleshooting guide will be provided with the Virtual Slugger.

Risk: High

Test Approach: Multiple reviews will be done for the troubleshooting guide to make

sure it is satisfiable for the customers to use the product.

5.5 Performance Requirements

5.5.1 Latency

Description: Latency is currently an issue with virtual reality devices and sensors,

however, user should experience as little latency as possible.

Risk: High

Reason: Oculus Rift DK2 has its own latency tester which will be used to optimize the

latency of Oculus Rift. For sensors, we will reduce the interference for maximum

optimization.

5.5.2 Graphics

Description: The user should experience smooth gameplay, animations and interaction

when using the Virtual Slugger.

Risk: High

System Test Plan

Page 44

Test Approach: Game will be played on the computer based on Packaging Requirements

and will be reviewed for the smooth gameplay and updated as necessary.

5.6 Other Requirements

5.6.1 User Friendly Interface

Description: The Virtual Slugger must have an intuitive and easy to use user interface .

Risk: High

Test Approach: Customer will be shown the prototype and will be review and updated

based on the user’s recommendation.

SRS ID Requirement Type Priority

3.1 Switch Hitting Capability Customer Critical

3.2 Setting Configuration Customer Critical

3.3 Hit Virtual Baseball Customer Critical

3.4 Real World Bat Customer Critical

3.5 Virtual Reality Batting

Environment

Customer Moderate

3.6 Feedback Customer Critical

3.7 Real Time Statistics Customer Critical

3.8 Learn Fundamentals of

Batting

Customer Moderate

3.9 Switch Pitching Customer Low

3.10 Mode Selection Customer High

4.1 Virtual Reality Device Packaging Critical

4.3 Xbox Controller Packaging Moderate

4.4 Sensors Packaging Critical

4.5 Software Packaging High

System Test Plan

Page 45

4.6 Computer Packaging High

5.1 Latency Performance High

5.2 Graphics Performance High

6.1 Simulator Sickness Safety Critical

7.1 Source Code Documentation Maintenance and Support High

7.4 Troubleshooting Guide Maintenance and Support High

8.2 User Friendly Interface Other High

Table 5-1 - Requirements

System Test Plan

Page 46

6. Features not to be Tested

This section consists of the requirements that will not be tested.

6.1 Packaging Requirements

6.1.1 Physical Baseball Bat

Description: A baseball bat will be provided for the user to interact with the

virtual environment.

Risk: High

Reason: Physical baseball bat cannot be tested but the interaction of the physical baseball

bat is already tested on the Customer Requirements.

6.2 Safety Requirements

6.2.1 Baseball Bat Hazard

Description: A warning label will placed on the product advising users to provide

adequate room when in use due to the hazards of using a real baseball bat.

Risk: Critical

Reason: User is responsible for safe use of the bat and the team breaking bat cannot

ensure the bat can be always used as intended by the user.

6.2.2 Mental Health

Description: A label that warns against excessive use will be affixed to the Virtual

Slugger as excessive use could affect the health of the user.

Risk: Mode

Reason: User is responsible for using the software in moderation and the team cannot

ensure that the users will adhere to moderation.

System Test Plan

Page 47

6.3 Maintenance and Support Requirements

6.3.1 Hardware Support

Description: Provide replaceable components for users if issue is within the scope of

hardware built by the team.

Risk: Moderate

Reason: Team is not responsible for maintaining the product.

6.3.2 Software Support

Description: Bugs reported by users will be handled by the software team and marked

with the appropriate priority level.

Risk: High

Reason: Team is not responsible for maintaining the product.

6.4 Other Requirements

6.4.1 American English Standard

Description: The Virtual Slugger must use the American English language as the

default for any text.

Risk: High

Reason: Not Testable

SRS ID Requirement Type Priority

6.2 Baseball Bat Hazard Safety Critical

6.3 Mental Health Safety Critical

System Test Plan

Page 48

7.2 Hardware Support Maintenance and

Support

Moderate

7.3 Software Support Maintenance and

Support

High

8.1 American English

Standard

Other High

Table 6-1 - Other Requirements

System Test Plan

Page 49

7. Overall Test Strategy

7.1 Overview

The nature of the Unreal Engine makes it difficult to test with a traditional software testing approach.

Video game testing typically is done by implementing a feature and then playing the game to see if it

works. The UDK also lacks proper testing framework to perform sufficient unit tests.

7.2 Strategy

Breaking Bat will use a module-based testing strategy in which each module will be tested individually as

possible. These modules will be tested in their own “sandbox” game executable and then be integrated

with the others. The integration of these modules will then be tested to ensure that they work well

together. Some modules depend entirely on another module being complete.

Once components are integrated and working well with each other, the simulation will then be tested with

the target audience. Team Breaking Bat’s sponsor has agreed to let his players test the Virtual Slugger and

provide feedback to the team.

7.3 Testing Metrics

The test cases described each have a risk associated with them. The risk denotes the level of severity of

failing the test.

● 1-Critical – A test that is marked with critical risk is required to pass for the system to be

accepted.

● 2-High – A test that is marked with high risk will be important for the system to meet the proper

expectations, but may not be required for the system to be accepted.

● 3-Moderate – A test marked with a moderate risk will not be required to pass for the system to

be accepted, but could have a reasonable impact on the final result.

● 4-Low – A test marked with low risk is also not required to pass and will have a minimum impact

if it doesn’t.

System Test Plan

Page 50

8. Criteria Specification

8.1 Overview

This section will be split into two parts: The first part consisting of the acceptance criteria and lists all

pass/fail criteria for each test. The following methods of testing will be listed and explained: Hardware

Testing, Unit/Module testing, Component/Subsystem testing, Layer testing, and System testing. The

second part will consist of suspension/resumption criteria that lists all criteria that may result in halting or

resuming the test plan.

8.2 Acceptance Criteria

8.2.1 Hardware Testing

The following 6 hardware components will be tested: The Femtoduino (accelerometer/gyroscope), The

Oculus Rift, the Kinect 2.0, an X-Box 360 Wireless Controller, Wireless Speakers, and a Monitor.

Test ID Hardware Component Pass Criteria Fail Criteria

H1 Femtoduino 1.) Records accurate

accelerometer and

gyroscopic data

1.) Cannot

send data

via

Bluetooth

H2 Oculus Rift 1.) Head tracking data

sent to Unreal

Engine.

2.) User is able to

move head to look

around the map.

3.) Display is

duplicated to the

monitor.

1.) No signal

detected

H3 Kinect 2.0 1.) Provides proper

body motion

tracking

2.) Accepts audio input

2.) Unable to

provide

data

through

USB

H4 X-Box 360 Wireless

Controller

1.) All controls work.

2.) All buttons are

1.) Unresponsi

ve Button.

System Test Plan

Page 51

responsive.

H5 Speakers 1.) User is able to

listen to proper

quality sound.

1.) No sound

is output.

H6 Monitor 1.) User is able to see

the simulation

clearly on the

monitor.

1.) Monitor

does not

display

simulation.

Table 8-1 - Hardware Testing Criteria

8.2.2 Module Testing

The Virtual Slugger contains 17 Modules that will each be individually tested with their own

pass and fail criteria.

Test ID Unit/Module Pass Criteria Fail Criteria

UI1 Femtoduino Plug-in Accelerometer/Gyros

cope data received

and calibrated

Data is not

retrieved/translated

UI2 Oculus Rift Plug-in Head tracking data is

validated

Data is not


UI3 Kinect Plug-in Kinect data is

validated

Data is not


UI4 X-Box Controller

Plug-in

X-box data

successfully

translated into data

the Unreal

Development Kit can

use.

Input is not


UP1 Baseball Bat Track bat’s

acceleration and

orientation to send to

the HUD

Cannot grab data

from plug-in or send

data to the HUD

UP2 Character User is able to control

in game environment

User is unable to

control in game

environment

System Test Plan

Page 52

UP3 HUD Outputs all live

statistics. Outputs

feedback at the end of

session

Cannot output live

statistics/feedback

UP4 Collision Boxes On collision,

respective actions

such as destroying the

ball are taken

Actions do not work

UP5 Menu Menu system can be

moved through

Menu system cannot

be moved through

UP6 Initializer Creates game off of

user’s customizations

from menu

Customizations not

working or game fails

to load completely

UP7 Pitcher Pitching animation

triggered by the user

saying “pitch”.

Animation does not

work correctly

UP8 Baseball Baseball spawns and

can be hit

Baseball does not

spawn/cannot be hit

UC1 Map Load the map Cannot load the map

UC2 Sounds Outputs correct audio

for scenarios

Cannot output audio

UC3 Textures Textures for materials

are loaded

Textures for materials

cannot be loaded

UC4 Static Meshes Loads all static

meshes

Static meshes unable

to load

UC5 Skeletal Meshes Loads all skeletal

meshes

Skeletal meshes

unable to load

Table 8-2 - Module Testing Criteria

8.2.3 Component Testing

The Virtual Slugger consists of 10 components (subsystems) that will each have their own pass

and fail criteria.

System Test Plan

Page 53


CI1 Plug-ins Appropriate data is

converted to be used

in Unreal Engine

Data cannot be

converted/passed to

the Unreal Engine.

CP1 Player Controller Virtual character and

bat can be controlled

by user

Virtual character and

bat cannot be

controlled by user

CP2 Statistics Analyzer Analyzes data given

to it and presented to

the monitor/Oculus

Rift

Data cannot be seen

CP3 Game Events Proper output

happens for each

event

Output is

incorrect/doesn’t

happen

CP4 Game Start Constructs game

environment with

customization from

Menu system

Cannot construct

game environment

CP5 AI Controller Autonomous behavior

of pawns work

correctly

Autonomous behavior

does not work

CC1 Level Outputs Map Cannot load map

CC2 Audio Outputs correct

Audio

Cannot output audio

CC3 Materials Outputs Materials Cannot load materials

CC4 Meshes Outputs Static and

Skeletal Meshes

Cannot load Meshes

Table 8-3 - Component Testing Criteria

8.2.4 Layer Integration Testing

The Virtual Slugger contains 3 distinct layers that will each have their own pass and fail criteria.

System Test Plan

Page 54


LI1 Input Processes all input

data and sends to

Processing Layer

Cannot process data

correctly/send data to

Processing Layer

LI2 Processing Correctly creates

game simulation and

user ability to interact

Cannot create

simulation/user

cannot interact

LI3 Content Holds anything that

needs to be loaded by

Processing Layer

Cannot be loaded by

Processing Layer

Table 8-4 - Layer Integration Testing Criteria

8.2.5 System Testing

Once all of the above tests have passed, the final phase of testing will be testing the Virtual

Slugger as a whole system. Below are the criteria that are needed for the system to pass or fail.

Note that if one of the previous tests has failed, this test will be temporarily suspended.

Test ID Pass Criteria Fail Criteria

SV1 Game installs successfully. The game fails to install

properly.

SV2 Game successfully loads the

main menu.

Any or all of the menu items

cannot be selected.

Main menu is not loaded

properly.

SV3 Game successfully interacts

with the Oculus Rift and

allows the user to see their

head movements in game.

User cannot see from a first

person perspective or external

distortion prevents the player

from observing the game

world as intended.

SV4 Game play is suspended when

pause menu is displayed.

Pause menu cannot be

displayed.

Game cannot be suspended

SV5 Virtual baseball can be ‘hit’

by the bat

Baseball cannot be ‘hit’

SV6 Audio such as crack of bat Audio does not work

System Test Plan

Page 55

hitting baseball works when

cued

SV7 Live stats are displayed Live stats cannot be displayed

SV8 The game provides proper

feedback

Game provides no feedback

or improper feedback

Table 8-5 - System Testing Integration Criteria

8.3 Suspension and Resumption Criteria

8.3.1 Suspension Criteria

Criteria listed below are those that point to problems serious enough to warrant test suspension.

Fault (Type) Requirement

Module Failure All critical tests must pass in order to move on to

Module Testing.

Subsystem Failure The Module Tests must succeed in order to

proceed with Subsystem Testing

Layer Failure The Subsystem Tests must succeed to proceed

with System Testing.

Hardware Failure Any of the provided hardware fail to work.

Table 8-6 - Suspension Criteria

8.3.2 Resumption Criteria

Criteria listed below allows tests to resume once the problems that caused the test to be

suspended are resolved.

Fault (Type) Requirement

Module Failure Critical Tests pass.

Module Tests pass.

Subsystem Failure Subsystem Tests pass.

System Test Plan

Page 56

Layer Failure Layer Integration Tests pass.

Hardware Failure All hardware restored to original state.

Table 8-7 - Resumption Criteria

System Test Plan

Page 57

9. Test Deliverables

9.1 Overview

All testing deliverables listed in this section will be documented, recorded, and included in the

final product.

9.2 Deliverables

9.2.1 System Test Plan This current document describes how team Breaking Bat plans to test the system software and

hardware.

9.2.2 Test Case Specifications

Each test case specification will be documented using the following criteria:

● Test Case ID: An ID associated with the test case

● Description: A description of the test being performed and why it is being

performed

● Input(s): The given inputs of the test case

● Expected Output(s): The expected output of the test case

● Process: A step by step walkthrough of how the test is performed

9.2.3 Test Case Results

Each test case result will be documented using the following criteria:

● Test Case ID: An ID associated with the test case

● Test Date: The Date the test was performed

● Name of Tester: The name of the person who performed the test

● Input(s): The given inputs of the test case

● Expected Output(s): The expected output of the test case

● Actual Output(s): The actual output of the test case

● Result of Test: Pass/Fail

● Comments: Any additional comments

● Bug ID: If there are any bugs, each one will be given an ID

System Test Plan

Page 58

● Bug Description: If there are any bugs, a description will be given of the bug with along

with the Bug ID

9.2.4 Bugs and Defects

Any bugs or defects that appear during the testing stages will be properly documented with the

following items:

● Bug ID: Each bug will be given an ID

● Test Case ID: Each bug will have the ID of the test case where it appeared

● Name of Tester: The name of the person who performed the test

● Test Date: The date the test was performed

● Bug Description: Each bug will have a description

● Inputs: All inputs used in the test

● Outputs: All output from the test case (expected and actual)

● Bug Comments: Any additional comments on the bug or defect

System Test Plan

Page 59

10. Test Schedule

WBS Task Name Planned Start Planned Finish Resource Name

2.3.3.1 Hardware Test Sat 9/27/14 Fri 10/10/14 Geoffrey Graham

2.3.3.2 Unit Test Wed 10/22/14 Thu 12/4/14 Ehidiamen Ojielu

2.3.3.3 Processing Test Tue 10/14/14 Tue 12/2/14 Geoffrey Graham

2.3.3.4 Content Test Tue 10/14/14 Sun 11/30/14 Roshan Lamichhane

2.3.3.5 Component Test Sat 9/27/14 Wed 10/22/14 Sean Gibeault

2.3.3.6 Integration Test Thu 10/30/14 Thu 12/4/14 Brandon Auwaerter

2.3.7 System Verification Test Wed 11/19/14 Tue 12/2/14 Brandon Auwaerter

Table 10-1 Test Schedule

11. Approvals

Name Signature Date

Mike O’Dell

Sean Gibeault

Brandon Auwaerter

Geoff Graham

Ehidiamen Ojielu

Roshan Lamichhane

Table 11-1 - Approvals

System Test Plan.docx

Documents