system test plan.docx
Post on 02-Jan-2017
225 Views
Preview:
TRANSCRIPT
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 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.
Number Requirement Description Priority
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.
Number Requirement Description Priority
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.
Number Requirement Description Priority
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.
Number Requirement Description Priority
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 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
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
retrieved/translated
UI3 Kinect Plug-in Kinect data is
validated
Data is not
retrieved/translated
UI4 X-Box Controller
Plug-in
X-box data
successfully
translated into data
the Unreal
Development Kit can
use.
Input is not
retrieved/translated
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
Test ID Unit/Module Pass Criteria Fail Criteria
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
Test ID Unit/Module Pass Criteria Fail Criteria
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
top related