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.
Since most of our functionality had been completed in Stage 1, Stage 2 was primarily a UI upgrade, moving from basic shapes and colors to complex images and gifs. We did add one extra tower, for a total of 5, and used the same tests from previous towers for this one. The difficulties we ran into for UI upgrades were issues with size requirements, and image location. We also experimented with sound, but it was poorly received by beta testers. Our defect tracking forum saw limited use with the beta testers, as most knew us personally and just contacted us through e-mail an IM.
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. The
majority of changes made for this Stage of development were cosmetic, and
testing was primarily UI testing, focused around creating images and objects,
rather than simple colored shapes, and testing their placement on the
grid. Testing for this was time
consuming and tedious, as many small changes on the order of tenths-of-pixels
were needed.
2. Detected
and tracked bug with placement of a Tower’s range radius, causing sidebar to
not register user’s clicks. Bug resolved
and fixed.
3. Detected
and tracked bug surrounding character overflow of name in
game-over-window. Bug resolved, will not
fix. Working on new Game-Over-Window for
Stage 3 release.
·
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 2, 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. Added logic for one new tower to game-play
logic. Tower had new values for cost,
range, and damage. The bullet for that
tower added a new graphic model for bullets, as well as new logic for the
bullet itself. Testing for this new
tower consisted of using our test-cases from previous game logic after new
tower/bullet logic was implemented.
2. Began testing on adding sound to the
game-logic. Created a Sounds class for
future use with a variety of mp3 files. Initial
choices in mp3 files were not well received.
Future decisions will be based on user feedback.
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
|
· 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 one 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 Stage 3. However, we will take the issue to heart, and make sure that a similar problem in the new game-over window does not develop.
|
Date |
Version |
Description |
|
April 4th, 2008 |
2.0 |
VVR Document Created |