Foo Sharks

VVP: Sonic Boxmo

Version: 1.0

CS 4500, University of Utah, Spring 2008

The Verification and Validation Plan (V&V Plan or VVP) sections given in this outline are guidelines to the contents of your V&V Plan. Include at least these sections. Your team may have good reasons for wanting to deviate from this proposed outline. In this case, you must motivate any deviations to the instructor. If a section is not applicable in your case, do not delete it; instead, give the topic heading and write "Not applicable."

This outline contains links to the appropriate sections.

1. Introduction and overview

1.1 Purpose of this Document

This document details the Verification and Validation process for the Sonnic Boxmo development project, it's components and interfaces.

1.2 Scope of the Development Project

Sonic Boxmo will be a puzzle game which will consist of novel and innovative features including a multi-cursor multi-player user interface and fast-paced music based puzzles, which will immerse the players into a unique musical environment. Each player in the game is going to have their own cursor and speaker, and will play in a shared 3D hardware-accelerated environment.

1.3 Definitions, Acronyms, and Abbreviations

MSI - Microsoft Installer (file extension)
SDS - Software Development Specification
SRS - Software Requirements Specification
VVP - Verification adn Validation Plan
VVR - Verification and Validation Results

1.4 References

Sonic Boxmo SRS
Sonic Boxmo SDS

1.5 Overview of Document

This document outlines the testing strategies for Sonic Boxmo and its components.

2. Reviews, walkthroughs, inspections, and audits

Document and code reviews will take place at team meeting(s) prior to the submission deadline of the document/project. Meetings are held daily

3. Component test plans and procedures

3.1 Component Test Strategy Overview

Synthsize representative test ipunt with predictable output and compare output generated by module. Also test with input of extreme valid values/size and invalid input to check error handling.

3.2 GraphicsMain

Use very large SceneLists and empty scene lists.
Set width and height to values beyond screen resolution.

3.3 DrawableObject

load a drawable object with a VERY large vertex list
create lots of drawable objects and randomly delete from the middle of the list to test list cohesion
specify invalid geometry (i.e. triangles with vertex count not a multiple of 3)

3.4 Material

attempt to load very large texture/bump map files
specify invalid texture/bump map path

3.5 AudioSample

test all possible sample rates and bit depths (even those that excede hardware capabilities)
incrementally increase the number of simultaneous samples being played back until the system fails to find hard limit of simultaneous samples

3.6 BoxmoMain

Play test. See section 4.

3.7 PuzzleField

load variable sized fields and test element placement and identification
test every possible rotation of elements
attempt to index element out of bounds
attempt to rotate an invalid element group

3.8 PuzzleElement

while testing PuzzleFied, attempt all possible valid and invalid calls to update and explode
observe for proper interface behavior in PuzzleField testing

3.9 Player

manually test input mapping

3.10 MusicBar

load track with lots of notes and attempt to display them
specify a very large active section and 0 active section

3.11 MusicTrack

create invalid song file

4. System test plans and procedures

4.1 System test strategy overview

The game will be play-tested in several stages:
Closed alpha testeing will be done until no bugs present readily through testing by group members.
After the closed testing other volunteer testers will be brought in to test the product end to end(download, install, setup, play, uninstall)

4.2 Single Player Mouse Control

one player play all available puzzles to completion with a mouse

4.3 Multiplayer mouse control

same as 4.1 but with 2,3,4 players

4.4 Single Player Wii Remote control

same as 4.2 but with a wii remote instead of a mouse

4.5 Multiplayer Wii Remote control

same as 4.4 but with 2,3,4 players

4.6 Multiplayer mixed input (some mice, some Wiimotes)

some number of players using mice, others using wii remotes

5. Defect tracking plans

In this section, the team will discuss their procedures for defect tracking. This includes a brief discussion of the tool, the team's procedures for reviewing defect reports on a regular basis, and the team's process for assigning responsibility for a defect to specific individuals. This section should also discuss the severity codes that will be assigned.

Defects will be tracked through several means:

Defects with specific modules will be logged in a defect log file for that module and stored on the SVN along with the project.

Alph/beta testing defects will be tracked in a log for each build.

6. Traceability from SRS to SDS

SRS Section SDS Section Notes
3.1 External Interface Requirements Component Descriptions: 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12

Description: What the program looks like to the end user.
Testing procedures are outlined in sections 3 and 4 of this document.
Variables:
3.2.1 Options Menu 3.12 MainMenu

Description: User choice interface that provides easy access to game settings.
Testing procedures will be to demonstrate all possible game settings. Testing procedure will be making sure that variable printouts and/or inspections are as expected.
3.2.2 Gameplay Mode 3.6 BoxmoMain Description: Allow 1-4 players to play the game
3.2.3 Sand-Box Mode (level Editor) 3.6 BoxmoMain Desctiption: BoxmoMain handles sandbox mode as well as game-play mode.
Testing: See ssection 3.6 of this document

7. Test-requirements cross-reference matrix

Performance requirements in the 3.3 of the SRS will be tested as per section 4 of this VVP.

SRS Section Description Testing Notes
3.2.1 Options Menu Main menu ensure that all game options produce the desied effect in game
3.2.2 Gameplay Mode main game mode start game ensure that setup is correct... play to
3.2.3 Sand-Box Mode (level Editor) No puzzle, just place notes and make a song Manually check file ouput format and test in game for compatibility

See also: traceability matrix in section 6

8. Acceptance test and preparation for delivery

8.1 Procedure by which the software product will be acceptance tested

The final product will be black-box tested as per section 4 of this VVP prior to release.

8.2 Specific acceptance criteria

The product will be considered acceptable when:

The above conditions mut be met in all scenearios outlined in section 4 of this document.

8.3 Scenario by which the software product will be installed

The installation process will be automated via the MSI install builder packeged with Visual Studio.

9. Additional information

N/A