Documentation Standards

VVR v1

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 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.

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

I/O – Input and Output

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. Summary of Results

We tested each component of the system separately in component testing, and jointly in system testing. As this stage of our project is a Beta, any errors found were identified and resolved in the day-to-day development of the project. Our Beta is ready to be release to beta testers, so looking forward, once we receive feedback from them, the real Validation and Verification process will begin.

3. Results from reviews, walkthroughs, inspections, and audits

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.

4. Results from testing

4.1 Summary of component test

· 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. The testing was done in two components, pre- and post-integration with the game-play logic component. Because our development was a test-as-you-develop process, the testing process was interwoven in the development. As such, trying to determine a quantitative bound on time is problematic. Now that we are in Beta testing, however, we will begin to devote time and man-power to testing exclusively.

· 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.

· 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. The game-logic testing was also done in pre- and post-integration pieces. And just like the game-play window, the testing and development was done simultaneously, and thus problematic to quantify.

4.2 Summary of integration test / testing product as a whole

Integration Test – Both game-play components needed integration testing to determine how they interacted together, specifically handling I/O. All members of the team were responsible for various parts of the integration testing, with Matt and Casey primarily responsible for game-play window, and Mark and Tyler responsible for game-play logic. Before integration, each component handled its own I/O, but after integration components were assigned to specific pieces of the overall I/O. Integration and integration testing took the most man-hours from the team, and revealed the most issues, with a high percentage of time spend on handling I/O.
End-to-End Testing – End-to-end testing was the final piece of Stage 1 testing that we performed on the Online TD and arguably took the least time. Once integration testing was complete, end-to-end testing was a simple extension of the various parts integration testing verified. Again, each team member was responsible for some end-to-end testing, but at this point no person was more responsible for a component, as there were no longer any components, just a game.

5. Evaluation of the process

5.1 Evaluation of test cases

When designing our test cases, we treated each test case as a goal. Things like “User is able to choose game mode” is one test case. These were effective both for testing and developing, which fit our pre-beta development 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.

5.2 Results from defect tracker

As stated earlier, defect tracking was largely problematic with the interweaving of development and test. However, as we began setting up our beta tester defect tracking, we decided on an online forum format, with separate threads being created for specific defects. This will also allow beta testers to provide a basic “how I feel about the game” in threads dedicated not to bugs, but general feedback.

5.3 Lessons learned

· Breaking a large project into components, and working on those initially was also quite helpful for us, and worked well.

· Most of our significant development and testing was done post-integration. Keeping the components separate was definitely a good idea, but it can only take you so far, and once you begin to integrate, the real work begins.

· 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.

6. Outcome of acceptance test and delivery

6.1 Procedure by which the software product will be acceptance tested

We feel confident that our game is of high enough quality to distribute to beta testers. We are beginning our cycle of receiving complaints and feedback from the testers, which will lead to changes and rereleases of the game.

6.2 Specific Acceptance Criteria

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.

6.3 Scenario by which the software product will be installed

No installation is necessary, for the closed beta we simply inform our beta testers of the URL and password.

7. Summary of open issues

As detailed earlier, there are no open issues in our defect tracker.

Date	Version	Description
March 11, 2008	1.0	VVR Document Created