VVP

Version 1.0
February 19, 2008

Online Tower Defense

Epicurity

Casey | Mark | Matt | Tyler

1.0 Introduction and Overview

1.1 Purpose of this Document

This is the Verification and Validation Plan (V&V Plan or VVP) for Epicurity’s Tower Defense game. This document will outline the verification and validation of our Tower Defense Game in addition to test plan, procedure, and preparation and delivery of the final product as agreed upon by the customer and the project team.

1.2 Scope of the Development Project

Team Epicurity will develop an online Flash based Tower Defense game. Tower Defense is a genre of video games popularized by Starcraft and Warcraft 3, but has recently taken off as an online flash game. So far, however, the flash versions pale in comparison to the originals. We are determined to reduce this gap, and make one of the best tower defense games on the internet. When users first enter our web-page the flash application will launch, presenting game-play options such as difficulty and game modes.

1.3 Definitions, Acronyms, and Abbreviations

AS – Action Script

TD – Tower Defense

1.4 References

Desktop TD - http://www.handdrawngames.com/DesktopTD/game.asp

Vector TD - http://www.candystand.com/play.do?id=18047

Blizzard Entertainment - http://www.blizzard.com/

1.5 Overview of Document

The purpose of the Verification and Validation Plan is to update our descriptions of Scope, Acronyms and Abbreviations, References, Reviews, Walkthroughs, and Audits. It also describes the test plans, procedures, and requirements tracking we will use in our project. Finally, it describes the preparation and delivery of a final product, once testing is complete.

2.0 Reviews, Walkthroughs, inspections, and audits

Reviews: Similar to the agile process model, we will begin each team meeting with a short and simple overview of each member’s progress the previous week, along with any complications team members encountered. We will also have a defect tracking meeting. Each defect tracking meeting will begin by reviewing the previous week’s test result web-page, with any failed tests being discussed by testers and designers responsible for the component tested. Assignments may also be given out for further testing and resolution of the defects.

Walkthroughs: Our walkthroughs will be a relatively informal review technique in which a developer leads the other team members through an assigned section of code, and the review team will identify possible problems and improvements.

Inspections/Audit: Our team will use Inspections and Audits as a technical review of small pieces of code with a focus on the review process and possible ways for team members to improve their code.

3.0 Component Test Plans and Procedures

3.1 Component Test Strategy Overview

The following items will be required in each of the Component Tests:

Testing Process: The testing procedure described in this plan, given in terms of phases and activities.
Requirements traceability: Relate the testing to the requirements given in the SRS (this will be strongly related to what you given in the test requirement cross-reference matrix).
Items or components tested: The items being tested; identify them as precisely as possible.
Testing schedule and resources: The overall testing schedule and resource allocation.
Test recording procedures: How the results of the tests will be systematically recorded. It must be possible for an outside agency to inspect the test plan, the test cases, and the test results to determine that the testing process has been carried out correctly.
Hardware and software requirements: The software tools that are needed for running these tests as well as any hardware that will be needed.
Constraints: Any constraints that will affect the testing process.

3.2 Game-Play Window

Testing Process: The game play window will be tested in two phases. First we will test the sidebar assuming that the game-play logic is working correctly. Next, we will test the top bar under the assumption that both the game-play logic and sidebar are working correctly.
Requirements traceability: The sidebar will display all the towers that a user can currently build. Hovering over a tower in the sidebar will display information about that tower. Selecting a tower that has already purchased will display information about that tower as well as provide options including upgrading and selling the tower. The top bar will display the current level, time till next level, a button to go to the next level, user’s life total, resource total, and point total.
Items or components tested: Top bar and sidebar.
Testing schedule and resources: We will write our tests before the game-play logic is implemented but because the sidebar and top bar rely on the game-play logic we cannot execute these tests until the game-play logic is finished.
Test recording procedures: Since our tests must be performed manually, we will fill out a template that documents a test procedure. These will be placed on the team website.
Hardware and software requirements: Flash.
Constraints: As ActionScript is a scripting language there is no debugging and therefore all testing must be done manually.

3.3 Menus

Testing Process: The menus will be tested in two phases that can be done independent of each other: the game-play options and the scoreboard. The scoreboard tests will assume working functionality of game-play logic, while the game-play options are run at the start of the game and don’t depend on anything.
Requirements traceability: The game-play options testing covers the User Interface requirements: a simple menu will appear that allow users to select their game play options and start the game. The scoreboard testing covers the functionality requirements: Enter Name.
Items or components tested: Game-play menus and Scoreboard.
Testing schedule and resources: We will write our tests before the game-play logic is implemented but because the scoreboard relies on the game-play logic we cannot execute that test until the game-play logic is finished.
Test recording procedures: Since our tests must be performed manually, we will fill out a template that documents a test procedure. These will be placed on the team website.
Hardware and software requirements: Flash.
Constraints: As ActionScript is a scripting language there is no debugging and therefore all testing must be done manually.

3.4 Game-Play Logic

Testing Process: The game-play logic will be the core of our program and will consist of four phases: path-finding AI, tower target selection and firing, enemy’s path following, and game "state".
Requirements traceability: User interface requirements are covered by these tests because all of the user interface components depend on working game-play logic.
Items or components tested: Game-play options, sidebar, path-finding AI, tower target selection and firing, enemy’s path following, and game "state".
Testing schedule and resources: Since so many components are so dependant on game-play logic, it needs to be one of the first tests completed, and therefore will have a majority of our resources devoted to finishing.
Test recording procedures: Since our tests must be performed manually, we will fill out a template that documents a test procedure. These will be placed on the team website.
Hardware and software requirements: Flash.
Constraints: As ActionScript is a scripting language there is no debugging and therefore all testing must be done manually.

4.0 System Test Plans and Procedures

4.1 System Test Strategy Overview

The following items will be required in each of the System Tests:

Testing Process: The testing procedure described in this plan, given in terms of phases and activities.
Requirements traceability: Relate the testing to the requirements given in the SRS (this will be strongly related to what you given in the test requirement cross-reference matrix).
Items or components tested: The items being tested; identify them as precisely as possible.
Testing schedule and resources: The overall testing schedule and resource allocation.
Test recording procedures: How the results of the tests will be systematically recorded. It must be possible for an outside agency to inspect the test plan, the test cases, and the test results to determine that the testing process has been carried out correctly.
Hardware and software requirements: The software tools that are needed for running these tests as well as any hardware that will be needed.
Constraints: Any constraints that will affect the testing process.

4.2 System Test Description

Testing Process: This test will be run in one phase, the end-to-end phase.
Requirements traceability: The requirements that are covered by this test are: Enter Game Play Settings (3.2.1), Play Game (3.2.2), and Enter Name (3.2.3)
Items or components tested: End-to-end testing will test all components.
Testing schedule and resources: System testing will be done after all component testing has finished. Beta testers will be involved, and the group will only be working on System testing, so all resources can be devoted to the testing.
Test recording procedures: Since our tests must be performed manually, we will fill out a template that documents a test procedure. These will be placed on the team website.
Hardware and software requirements: Flash.
Constraints: As ActionScript is a scripting language there is no debugging and therefore all testing must be done manually.

5.0 Defect Tracking Plans

Defect tracking will be handled by a combination of Test results recording with an online recording page, and defect tracking meetings. The Test results recording page will be a template describing each test run, what it was testing, who was testing it, what the results were, and if there were errors, steps to reproduce. Each defect tracking meeting will begin by reviewing the previous week’s test result web-page, with any failed tests being discussed by testers and designers responsible for the component tested. Assignments may also be given out for further testing and resolution of the defects.

6.0 Traceability from SRS to SDS

requirement	SDS location
Select Game-Play Settings	Section 2.3
Play Game	Section 2.3
Enter Name	Section 2.3

7.0 Test-requirements cross-reference matrix

profile specific user info (string of characters)

identifier	description	test means	variables	system functionality	comments
Select Game-Play Settings	Allows the user to set certain game play options to their liking so that the game will be more enjoyable.	Black box testing	username (string of 4-12 characters) password (string of 8+ characters)	Allows the user to set certain game play options to their liking so that the game will be more enjoyable.	None
Play Game	Allows the user to play our Online Tower Defense game.	Black box testing	username (string of 4-12 characters) password (string of 8+ characters) real name (string of characters) email address (string of characters)	Allows the user to play our Online Tower Defense game.	None
Enter Name	Allow users to enter a name to be associated with their score so they know how they compare to other players on the internet.	Black box testing	User profile and info.	Allow users to enter a name to be associated with their score so they know how they compare to other players on the internet.	None

8.0 Acceptance Test and Preparation for Delivery

8.1 Procedure by which the software product will be acceptance tested

Once we feel confident with the quality of our game, we will distribute our game to beta testers. We will then enter a cycle of receiving complaints and feedback from the beta testers, from which we will make changes and rerelease the game to the beta testers, until no more feedback is provided.

8.2 Specific Acceptance Criteria

In order for the product to meet the acceptance criteria our clients must be able to access and play our game online. When they visit our website we need to prompt and accept the game-play settings from the user. Then we must allow them to play the game with the settings they requested. We they are finished playing the game we must allow them to enter in a name to be associated with their score.

8.3 Scenario by which the software product will be installed

This will be done by simply providing our clients with the URL for our game.

VVP

Version 1.0 February 19, 2008