This is the Verification and Validation Results (V&V Results or VVR) 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.
TD – Tower Defense
I/O – Input and Output
UI – User Interface
IM – Internet Messenger
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/
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.
Continuing our User Interface focus from Stage 2, Stage 3 saw improvements in game features like starting a new game and using keyboard shortcuts to allow users to interact with the game. Our UI design saw upgrades in the side and top bars, as well as the background and information area. The only difficulties we ran into during this Stage of the process were issues of UI design and theme. When integrating keyboard shortcuts, however, we ran into a large problem with inconsistency. Sometimes the keyboard shortcuts were detected, other times it would not. Because of this, we have left keyboard shortcuts out of our Stage 3 release, and is instead an open issue.
Reviews: Similar to the agile process model, we began 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 also had a defect tracking meeting. Each defect tracking meeting began 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.
Walkthroughs: Our walkthroughs were 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 did not need to use any inspections or audits.
·
Game-Play
Window – The game-play window testing was done using ActionScript
3.0 in Adobe Flash, and Matt and Casey each shared an equal ownership of this
testing.
1. As
with Stage 2, in Stage 3 most game-play window changes were cosmetic and required
no new testing. Ran tests similar to
Stage 2 tests, and made sure no pieces were broken by the addition of new
graphics.
2. One
game-play window change was the addition of a “Play Again?” option. This addition made changes to both game-play
window and logic, and as such required full end-to-end testing to verify no new
bugs were introduced.
·
Menus - The game-play window testing was done using ActionScript 3.0 in Adobe Flash, and Matt was the primary
tester for this component. This
component testing was done first, as it depended on no other components, and took
the least time.
1. No
new menus were added with Stage 3, so no new testing was needed, just made sure
that no changes made adversely affected the existing menus.
·
Game-Play Logic - The game-play window
testing was done using ActionScript 3.0 in Adobe Flash,
and Mark and Tyler equally shared ownership of the game-logic testing.
1. Made
various changes to the beam towers to resolve a known issue with beam-tower
bullets. Testing for this issue involved
recreating the known issue, and verifying it was resolved.
2. Added
logic for the “Play Again?” option. As stated
earlier, this required full end-to-end testing to verify no new bugs were
introduced.
3. Fixed a known bug where upgrades were not
allowed if a player had exactly enough resources for that upgrade.
4. Added functionality for in-game keyboard
shortcuts. However, during testing, got
inconsistent results and bugs that were difficult to
reproduce. Left this as a known issue,
and removed from Stage 3 code for further review.
When designing our test cases, we treated each test case as a goal. Something like “User is able to choose game mode” is one test case. These were effective both for testing and developing, which fit our test-as-you-develop process. As the Online TD became more evolved, many test cases were added like “User is able to upgrade tower.” These test cases will form the foundation of our regressing testing, and will continue to be verified going forward. As we receive feedback from beta testers, new test cases will be created to address any issues they come up with.
Bug Number |
Summary |
Component |
Reporter |
Assigned |
Result |
1
|
Name overlaps
on game-over window
|
Game-play
window
|
Casey Campbell
|
Casey Campbell
|
Resolved –
Will not fix. New game-over window in
Stage 3
|
2
|
Sidebar
buttons don’t respond if tower range radius overlaps them
|
Game-play
window
|
Matt Brown
|
Casey Campbell
|
Resolved –
Fixed. Moved grid to the back of the
game-window’s DislpayObjectContainer
|
3
|
Beam tower
bullets disappear and reappear randomly when firing horizontally
|
Game-play
logic
|
Chris Sontaq
|
Mark Hopkins
|
Resolved –
Fixed.
|
4
|
Upgrades could
not be made if resources matched exact cost of upgrade.
|
Game-play logic
|
Chris Sontaq
|
Matt Brown
|
Resolved –
Fixed.
|
· Working on game-play first, and cosmetics second allowed us to get a working, albeit ugly, version out to beta testers sooner, allowing us to begin the iterative design process sooner, which will ultimately lead to a better project.
· Two of the biggest concerns for an online game are size and speed. Since our game needs to fit in a relatively small area, each part of the game is also smaller. This led to some difficulties finding and converting graphics to use in the game. Anytime a game is played online, network latency, or lag, becomes a huge issue. Some of our most interesting ideas for the game simply won’t work, as they will slow the game down too much.
· Communication is also key to a working project, especially with cross-focus teams like this one. Interaction with management and business can also bring about requirements and expectations that were not expected or prepared for.
Our game went over quite well with beta testers, they provided objective pointers about game-play and balance, as well as approached our game from a fresh perspective, allowing new aspects of the game to be scrutinized and tested.
Our current beta is not open to the public, and thus the beta testers must navigate through the main page to get to the game, it is essentially just one additional click and a password entry. When they visit our website we prompt and accept the game-play settings. Then we allow them to play the game with the settings they requested. When they are finished playing the game we allow them to enter in a name to be associated with their score.
No installation is necessary, for the closed beta we simply inform our beta testers of the URL and password.
We currently have two open issue, but no open bugs. We have decided not to fix a known bug in the game-over window, as a completely new and separate game-window is being developed for Final Product. However, we will take the issue to heart, and make sure that a similar problem in the new game-over window does not develop. We also have decided to remove keyboard shortcuts from Stage 3 for further review, as there are inconsistent bugs and erratic behavior.
|
Date |
Version |
Description |
|
April 11th, 2008 |
3.0 |
VVR Document Created |