-
Notifications
You must be signed in to change notification settings - Fork 0
Test Plan
J.U.N.I.O.R. is a full 3D, third-person adventure computer game intended for use on hardware running Windows, OSX, and Linux Operating Systems. This game has only a single-player mode and consists of three primary levels, with the third being composed of multiple instances effectively combined into a single level. The player's goal is to eliminate all enemies and defeat the final boss, while using a single energy meter to manage all resources (weapons, health, thrusters, etc.).
This document serves to articulate specific testing processes and requirements to facilitate an effective approach to isolating and correcting software and design errors within the game.
Testing for J.U.N.I.O.R. will attempt to isolate and correct errors within game logic, level design, playability, and any general or specific areas that may prevent proper execution of the game.
Quality Assurance will be responsible for conducting and recording all testing procedures as outlined in this document. The entire development team will be extensively involved with the testing process by locating bugs and working collaboratively on methods to correct those not easily fixed. All issues will be regularly conveyed to the Test Manager for review.
Functionality testing will be the primary form of testing with isolated unit tests conducted to check for errors within individual functions and components, such as with the player character's thrusters script. J.U.N.I.O.R. is being developed using the Unity 3D engine, which has the ability to operate on a wide range of computer hardware.
Inclusions
All of the custom game data and scripting will be tested. This will include character behavior and controls (weapons, thrusters, movement), triggers (item collection, level transition), enemy behavior (AI, attack radius, weapons), game data (level information, score). The levels will also be tested for proper collision checking and blocking to ensure the player has access only to the intended playing area. The sound system will be tested to ensure the correct sounds are played at their respective instances and background music is properly played.
Exclusions
The Unity 3D game engine will not be tested as it has not been modified by the J.U.N.I.O.R. development team and should not contain any additional bugs that are not currently defined by its author(s) or parent company.
Functional Testing
Character behavior. This will be regularly tested by repeatedly utilizing control functions rapidly to test for smoothness, proper sound effects, and appropriate responses. Weapons fire will be tested for proper instantiation of projectiles, sound effects, and ray-tracing (where applicable). Thrusters will be tested for appropriate particle and sound effects.
Enemy behavior. This will be tested through proximity movement into the agents' attack radius to ensure enemies target the player as intended, properly attack, and stop aggressing when their health reaches zero. Enemy weapons will be tested by collision with the player character to assess damage to player's energy level.
Weapon behavior. This will be tested by firing weapons at enemies and checking to see if proper instance/ray tracing effect is called and if enemy health level has be decreased appropriately according to the respective weapon damage levels.
Triggers. This will be tested by either entering the trigger area (as with level transitions) or by colliding with the appropriate mesh (as with power-ups). Triggers should cause their intended action(s) according to their purpose (door, item power-up, etc.).
Game data. This will be tested by viewing if all relevant game data is being properly recorded/accessed. Scoring system should increment with each enemy kill and the level information should be properly displayed based on which level is currently active.
Level design. This will be conducted by play-testing to check for collision breaks in terrain mesh, blocking volume errors that may allow players to traverse into areas not intended by the development team, such as off a cliff or into an area that the player cannot get back out of, as well as aesthetic considerations, such as proper texture tiling.
Interface Testing
The user interface will be tested by checking if proper game data is being displayed as intended. This would include the score counter (starts at zero and displays incrementation as intended), current weapon selection (displays an icon representative of the currently selected weapon), and proper level information.
Acceptance Testing
Final Acceptance Testing
Final acceptance will be considered when all errors that cause critical or major detraction from proper use of the game have been eliminated. Furthermore, all errors which do not largely impact the playability, usability, or maintainability of the game must be documented and approved by the Test Manager before exiting the testing process.
The testing process will be conducted individually by each member of the testing team on his/her personal computer system. The game will be loaded in first the windowed format for the first part of testing and then fullscreen format will be tested afterward. After loading the game, testers will check each section of the functional testing scope, then document and report any errors found.
Unit tests will be conducted on a case-by-case basis to check for errors within specific code or functions as requested by the Test Manager.
Entrance Criteria
All testing computers will be installed with the same version of J.U.N.I.O.R. to ensure all individual tests are conducted under the same circumstances. All other applications should be closed prior to the start of testing to maximize system performance.
Exit Criteria
All tests were completed according to plan and the system conforms to the Final Acceptance Testing criteria (see above).
This is contained in the Alpha testing phase of the development process. Integration testing will be a large portion of the testing process and will consist of testing all components and how they operate together. This includes the connection and transition triggering between levels and the integration of all core assets into a single game world. This phase concerns with assembling the individual facets of J.U.N.I.O.R. into a working, playable model.
The Beta testing phase will be conducted to ensure system readiness for final Gold Release and will consist of heavy play testing and enlist testers external to the development team.
Hardware components required
Test Host environments
Test Branch Software
Error Measurement System
####1. Orlando Camacho #####a. Test manager #####b. Provide technical direction #####c. Acquire appropriate resources #####d. Report to management ####2. Test Designer #####a. Generate test plan #####b. Evaluate the effectiveness of the testing #####c. Compile test cases and get the ready for Acceptance testing
####1. John Berg #####a. Test Designer ######i. Generate test plan ######ii. Evaluate the effectiveness of the testing ######iii. Compile test cases and get the ready for Acceptance testing
####2. David Emerson #####a. System tester ######b. Execute test ######c. Log results ######d. Repair errors ######e. Document errors/bugs
####3. Eric Cowen #####a. System tester ######b. Execute test ######c. Log results ######d. Repair errors ######e. Document errors/bugs
####1. Orlando Camacho #####a. Set up business plan ####2. John Berg #####a. Set up business plan
####1. Orlando Camacho #####a. Provide support for testing as needed ####2. Eric Cowen #####a. Provide support for testing as needed
To be determined if needed
For the most part errors will be taken care of by the individual that made and will be detected by the group looking over the project three times a week in our meetings.
The way we will deal with changes to the project is to consult the team about them and get everyone’s approval. This will be similar to applying for a building permit but easier. The person wanting the change will present the change and the reason it would be better than what we have already. Then the group will weigh in on the matter.
If the situation is urgent then the team member can email each team member and ask for approval. If it is not urgent then the team member will wait until the next team meeting.
All changes will only be considered if it will actually enhance the project or keep the project from coming to a halt.
Status reports are due each week at the end of the week where we write what we have accomplished as a team and then mark what we accomplished as an individual. This not only lets the producer know where we stand but also lets us know how much work we put in and how long a similar task may take in the future.
Each week Team A will have three meetings at which we review what we have accomplished and what we need to accomplish. We also look at whether what we have accomplished meets the criteria set for us. If not then we improve it and move on.
Review Points
- Usability – How easy is it to pick up and use
- Number and types of bugs – No bugs that crash the game are allowed and few minor bugs should be present.
- Typos – All documents should be spell checked and proof read for grammar errors and none should be left in.
- All content is present – any documents should include every piece of information necessary to perform its purpose.
Some issues that may arise are:
- Hardware on some computers may not support the game – this is highly unlikely but there are a few computers that don’t support DirectX 9.
- A team member doesn’t know how to do a certain task – This is likely to happen from time to time but each team member will use every tool available to figure it out or find a suitable alternative.
- Third party assets – Third party assets need to have proper credit given to the author of the content.
Some Risks include:
- Project scope – The scope of the project is small and should be able to be completed in the amount of time given but some of the issues and other risks could slow progression and make it harder to meet the deadline.
- Changes to the project – This could cause the project to grow to large if not handled correctly.
- Power failure and loss of network – This could happen anytime and is likely to happen at least once. Work will not be able to be accomplished without power and/or network connection.
Some assumptions include:
- Team member’s lack of knowledge in a subject – We are all brand new so we don’t know everything. There will be something that we need to do at some point that we will need to seek help for.
- Power failure and loss of network – This is bound to happen at some point and most likely will only last a few hours. If a team member has power and no network connection they can still work on their tasks but will not be able to share their progress until they regain connection.
Home | Art Assets List | Audio Asset List | GDD | Pitch Document | TDD | Team Charter | Test Plan