CS4500 Verification and Validation Results 1
March 10, 2008
Team Here For Beer
1. Introduction and Overview
1.1 Purpose of this Document
The purpose of this document is to describe the results of the verification and validation performed as described in Verification and Validation Plan document.
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.
- VVP - Verification and Validation Planning
1.4 References
Flash Tower Defense Game, Vector Based
Another Tower Defense Game
1.5 Overview of Document
The Verification and Validation Report is a document outlining the testing, structure, and verification of the software that has been completed.
2. Summary of Results
All tests complete up to this point have been successful. Some issues were discovered as a result of the process described in the VVP. These issues have all been dealt with and resolved.
- Example: In order for particles to be rendered some options of the Direct3D device had to be set. As a result our previous implimentation of triangle rendering stopped working. This issue was brought to the groups attention by Chris. He discovered the issue when he was doing a review. On our next weekly meeting the issue was resolved.
There are more test to be written and more reviews to be done.
3. Results from reviews, walkthroughs, inspections, and audits
Our weekly meetings proved to be very successful. We discussed problems that we found during the week and worked together to solve these issues. Once the issues were solved the interested parties confirmed the fix was in fact correct. Quality assurance tests were mostly performed by Chris. Who optimized and debugged several issues.
Our Quality Assurance tests consisted largely of Code Viewing, and Unit Test writing. From these Reviews, the reviewer requested additional Walkthroughs, Inspections, or Audits as necessary.
- Additional walkthroughs were performed on several components of the system.
- Particles
- Primitives
- Map description files and structure
- Our two tear test plan and Procedure results.
- Test First procedure results:
- Each team member has done a great job in first testing their components before completing an assigned task as part of their regular development process.
- Weekly Quality Assurance Reviews Results:
- Were conducted during our weekly meetings, they provided great feed back to the developer and gave the developer a chance to teach the team how that particular component works with the rest of the system. In some cases recommendations were made for changes to be completed the following week, in other cases everything worked as expected.
- Test First procedure results:
In as far as the implementation has gone, no unit tests have been written. All tests and quality assurance that has happened, happened via methods described above.
4. Results from testing
4.1 Summary of component test
The team has been very good about keeping the project clean. We have no incidents in where a team member broke the code. Preventing other members from completing task.
| Component | Pass/Fail | Explanation | things left to do |
| Graphics Rendering | PASS | The team has been able to render many independent graphical components. These have all been tested via methods described above. | refine/debug |
| User Interface | PASS | The team has been able to render many independent user interface components. These have all been tested via methods described above. | Finish placing and interacting with towers |
| Gameplay System | PASS | Development of this component has had little progress, because this component cannot be implemented until the graphics rendering and user interface component is nearly complete. But what little work that has been done. Is working correctly and passing tests | Write game logic/control game play experience |
| High Score Server | PASS | This is one of the last components the team will be focusing on. The web server has been written but as of yet has no front end. The web server is passing all tests | Write flash front end |
5. Evaluation of the process
Overall our process has been a resounding success.
5.1 Evaluation of test cases
The corner stone of our process is our weekly meetings. In these meeting we have done most of our review work. Discovered issues, resolved issues and assigned new reviews to be completed by the next weekly meeting. While few unit tests have been written they have proved effective at preventing regression. Also visual inspection by our build master Dax, he has spotted many issues and this has resulted in a cleaner more well designed product. Other team members have done a great job of finding problems and recommending solutions and design philosophies to improve the system.
5.2 Results from defect tracker
The native Microsoft memory leak detector in Visual Studio has report approximately 73k of leaked memory. We are currently working on finding this memory leak, but it seems to be benign, as in it is always 73k, never larged no matter how long the program is left running.
5.3 Lessons Learned
Our process has worked very well for us so far. Due to the nature of the game we are writing and the component most of the effort has been placed upon. More unit tests will be required as we move to less visual parts the system. So far the whole team agrees that everything has gone very smoothly. We feel that we are making good progress, and have worked very hard to get to where we are now. There is still plenty of work to do and we hope that we will complete all the components and tests we have described in these documents.
6. Outcome of acceptance test and delivery
6.1 Acceptance Test Summary
Systems tested
- Graphics Rendering - PASS
- Gameplay Logic - incomplete
- Map System - PASS
- Level System - incomplete
- Highscore uploading - Not Yet implemented
- Highscore browsing - Not Yet implemented
- Testing Schedule and Resources: System tests for all implemented systems have passed.
- Test Recording Procedures: Tests for rendered graphic have been kept in order to continually confirm that no component implemented has broken the functionality of another system component.
- Hardware and Software Requirements: The system environments have provided few obstacles. Each team member been able to run the application and has a machine capable of meeting the hardware and software requirements.
- Constraints: Testing has been limited to methods described above. Extensive tests are beyond the means of this project.
6.2 Graphics Rendering and User Interface Testing Results
The game play has remained very smooth and several optimizations have insured that we stay with in our hardware specs for an enjoyable gameplay experience. Particle effects and animations are in place and working.
- Input: User Interface Interactions - PASS
- Expected Output: Known responses to User Input - incomplete
- Expected Output: graphical environment - PASS
6.3 Gameplay Logic Testing
This entire component is still in progess. Including leveling system, but the map system is up and running and passes all its tests.
- Input: User Interface Interactions - PASS
- Expected Output: control of graphical environment - incomplete
6.4 High Score Server System Testing
The server has been written but the input is incomplete.
- Input: High Scores from HFBTD game client - incomplete
- Expected Output: List of all High Scores from HFBTD High Score submissions in XML format - PASS
7. Summary of open issues
Much work is still to be done. But we are almost finished on the graphical components of the system. Next the team will be focusing on the game play logic. At this time there are not open issues or problems that the team is blocked on.
