CS4500 Verification and Validation Plan

February 22, 2008

Team Here For Beer



1. Introduction and Overview

1.1 Purpose of this Document

The purpose of this document is to describe the process and methodology used to determine if the software is functioning as intended and designed.

1.2 Scope of the development project

A real-time strategy game titled: Here For Beer Tower Defense will be developed. The game will be made using C++ and the Microsoft DirectX 9.0 SDK. The game will be similar in genre to current hit Flash-based games (see: 1.4 References Section) but will harness the power of modern graphics hardware. The single player game will consist of a single grid space in which a number of "maps" (number TBD) can appear. Each map will define a path in which the waves of enemies during that game will progress. The player can stop the enemies by building and upgrading towers on the grid, which will automatically attack enemies that are in their fire distance radius (in the tradition of typical tower based real-time strategy games).

The game will provide lasting single player value through its dynamic action and large spectrum of strategy, rather than through large amounts of graphical assets.

The project will also include a web front end programmed in Adobe Flash 9.0. The single player game can upload high scores via the internet to our server, which can later be browsed via the Flash-based front end.

1.3 Definitions, Acronyms, and Abbreviations

  • DX9 - DirectX 9
  • HFBTD - Here For Beer Tower Defense
  • RTS - Real-Time Strategy
  • SRS - Software Requirements Specification
  • Twitch Game - A type of game where users must react quickly to circumstances in order to continue playing (such as Tetris)
  • UI - User Interface
  • Wave - A Group of enemies, or other entities that will arrive, and attempt to depart together.

1.4 References

Flash Tower Defense Game, Vector Based
Another Tower Defense Game

1.5 Overview of Document

The Verification and Validation Plan is a document outlining the testing, structure, and verification of the software. In order to further verify the software, each component of the system will be thoroughly tested on its own, and while operating as part of the larger software system.

2. Reviews, Walkthroughs, Inspections, and Audits

As a development team, we will meet every week. During these meetings, we will assign not only development of components to individual members, but also Quality Assurance of components of other team members. The Quality Assurance tests may be performed by a single member of the team, or together as a group.

These Quality Assurance tests will consist largely of Code Viewing, and Unit Test writing. From these Reviews, the reviewer may request additional Walkthroughs, Inspections, or Audits as necessary.

3. Component Test Plans and Procedures

Our team will implement a two tiered plan for Testing Procedures.

  • We will implement a Test First procedure with each major component of the game. The Developer of any particular component must first test that component, and meet certain requirements before implementing it into the larger software system.
  • Weekly Quality Assurance Reviews will help to verify the soundness of any newly completed components. These reviews consist of Code Overview, and are the starting point for any additional Walkthroughs, Inspections or Audits.

3.1 Component Test Strategy Overview

Components will be tested as they are developed using the Test First methodology. The main testing methods will be Unit tests, and Assertations.

Component Test – Where possible, component tests will be done in an automated framework primarily with assertion tests. Due to the very nature of the project, many tests may need to be done in an instance test type environment.

System Test – A system test will put together groups of components that perform a given functionality together. Our Agile development process, along with our Test First procedure for testing individual components, makes it likely that System Testing will be a large part of our whole testing procedures. Testing the core of the project, the Game itself, will consist largely of System tests between the various graphic drawing components, and game logic components.

  • Testing Process: Where possible, automated Assertation tests will be used to verify the functionality of the software.
  • Systems to be tested
    • Graphics Rendering
    • Gameplay Logic
      • Map System
      • Level System
    • Highscore uploading
    • Highscore browsing
  • Testing Schedule and Resources: The team will develop components using a Test First Architecture where it is applicable. Due to the very nature of a Real Time Game, much of the testing will likely be System tests.
  • Test Recording Procedures: Our Agile development process may allude to much of the System Testing done in the actual software system, in these cases any test methods will be properly commented, and kept for future use. In any situations where a testing harness is used outside of the main system, versions of this will be saved for later review.
  • Hardware and Software Requirements: The software will be developed with Visual Studio 2005 and DirectX 9.0. The user must have the DirectX 9.0 or later runtime installed on their system in order to run HFBTD. The user must have a DirectX 9.0 or compatable Video Card on the system as well, in order to use the DirectX 9.0 runtime. There will be Hardware Verification testing on several systems that meet these requirements.
  • Constraints: Due to the scope of the project, and the situation under which it is being developed, our Team may not have the resources to do the kind of exacerbated testing required for a full release in the Real World.

4. System Test Plans and Procedures

4.1 System Test Strategy Overview

Our Test First implementation procedures should keep the code very clean. We will check the build of the software as a whole each time any of us work on it, and only commit code to our Source Repository if the newly added code does not prevent the project from building. If at any point new code breaks the existing software, it will either be reverted back to a earlier state, or corrected to pass any test cases it was failing prior.

4.2 Graphics Rendering and User Interface Testing

This will be one of the first systems developed for HFBTD, and will be responsible for all the DirectX rendering calls. We will use a small series of custom methods (and Assertations where applicable) to test the robustness of our Graphics Primitive components.

  • Case: Graphics Rendering Testing
  • Input: User Interface Interactions
  • Expected Output: Known responses to User Input
  • Environment: User Interface
  • Special Procedures: None

Pass/Fail - The Graphics Rendering system either works as desired, or it does not.

4.3 Gameplay System Testing

This will be developed in Tandem with the Graphics Rendering and UI system. This system is responsible for handling the game rules and how it interacts to User Input. We will use Assertation testing where applicable, however proper software run-throughs from the perspective of the End User will likely be the easiest and most useful method of testing our Tower Defense game. We will use a test level to Test all aspects of the game in a single level, as well as test the user level set before each major release.

  • Case: Gameplay System Testing
  • Input: User Interface Interactions
  • Expected Output: Known responses to User Input
  • Environment: User Interface / Graphics Rendering system
  • Special Procedures: None

Pass/Fail - The Gameplay system either works as desired, or it does not.

4.4 High Score Server System Testing

This will be a very straight forward system, and should also only require very simple Testing to verify its functionality. A few custom methods to test for desired functionality will be implemented on both the side of submission (HFBTD game client) and the side of retrieval (HFBTD web client). The Web client testing will also happen as part of testing this system via tests to that components' GUI.

  • Case: High Score Server System Testing
  • Input: High Scores from HFBTD game client
  • Expected Output: List of all High Scores from HFBTD High Score submissions in XML format
  • Environment: User Interface / Network
  • Special Procedures: None

Pass/Fail - If the server can accept scores from any reasonable connection, and return a list of all said scores to the web client, it Passes.

5. Defect Tracking Plans

Dax Self, our Build Foreman, will do bi-weekly builds of the Software System as a whole to ensure it is compiling and behaving as expected. We are using a Source Repository client to ensure that if there is a conflict in the code we will know who created the conflict and when it happened. Each team member will be responsible for fixing any conflicts that they have created. Our project tracking system (http://hereforbeer.caffinated.net/) will keep notes of any progress made with each code submission, and during our weekly meetings we will evaluate any existing bugs and assign a team member to correct them.

6. Traceability from SRS to SDS

Requirement from SRSReferences in SDS
3.2.2 Map Selection UI 3.2 Game Manager Component / 3.3 Game Renderer Component / Pseudocode section(s): DirectInput
3.2.3 Main UI 3.2 Game Manager Component / 3.3 Game Renderer Component / Pseudocode section(s): DirectInput, GameManager, GameEntity, Tower, Enemy
3.2.4 Map 3.2 Game Manager Component / 3.3 Game Renderer Component / Pseudocode section(s): DirectInput, GameEntity, Tower
3.2.5 Gameplay 3.2 Game Manager Component / 3.5 Game Entities / 3.6 High Scores Web Service / Pseudocode section(s): Game Manager, Game Renderer, Map, Level, DirectInput, GameEntity, Tower, Enemy
3.2.6 High Score 3.2 Game Manager Component / 3.6 High Scores Web Service / 3.7 High Scores Frontend / Pseudocode section(s): Game Manager, Score

7. Test-requirements cross-reference matrix

Requirement from SRSDetailed Description from SDSDescriptionTesting MethodAssociated System Functionality
3.2.2 Map Selection UI 3.3 Game Renderer Component A User Interface for the user to select a Type of Map to play on. Inspection Will directly interact with the Game Manager System by selecting the level to play on.
3.2.3 Main UI 3.3 Game Renderer Component Additional User Interface Components for various User Gameplay Interactions Inspection, Demonstration Will directly interact with the Game Manager System by building and upgrading towers and selecting any of the other various options available in the game
3.2.4 Map 3.2 Game Manager Component The user interface and logic that allows enemy path traversal and tower building abilities Inspection, Demonstration The map controls where towers may be placed and where enemy paths exist. It interacts with the game renderer by returning the map that should be rendered to screen.
3.2.5 Gameplay 3.2 Game Manager Component / 3.5 Game Entities Gameplay logic controls the progressive state of the game. Inspection, Demonstration The Game Manager controls the state of the game by creating/destroying game entities as appropriate. Each game entity encapsulates much of its own functionality to lessen the requirements of the Game Manager.
3.2.6 High Score 3.6 High Scores Web Service / 3.7 High Scores Frontend The high scores web service provides the means for high score submission and retrieval. The frontend allows players to efficiently view high scores. Analysis, Demonstration The game manager submits high scores to the web service and the frontend retrieves high scores from the web service.

8. Acceptance test and preparation for delivery

8.1 Procedure by which the software product will be acceptance tested

The team will target milestones for acceptance testing. Each milestone will provide a new feature or functionality that the game is capable of supporting. If these milestones are not met to the customers satisfaction, the negotiated changes will be made.

Current Milestones include:

  • setting up the DirectX SDK
  • drawing a simple primitive on the screen
  • drawing the game board (a simple grid)
  • mouse input
  • user menu
  • allowing the user to place towers
  • getting enemies to navigate map
  • have enemies navigating map while user placed towers shoot at them.

8.2 Specific acceptance criteria

The following checklist items will be part of the customer acceptance of the software. Items may be added or deleted as the customer gains further knowledge of the software and available features.

  • user menu provides access to game functions
  • user menu displays game state information (score)
  • user can place towers on the map
  • enemies move though the map
  • towers shoot at enemies in range
  • game play is progressive
  • game play is smooth
  • scores are submitted to the score web server
  • scores are visible via the web server interface

8.3 Scenario by which the software product will be installed

The executable and map files will be copied to a desired folder on the machine the software is being installed on.

9. Additional information

Ongoing code reviews are done by all members of the team.