Test Plan

COP 4331C, Fall, 2014

Modification history:

Team Name: Group 10

Team Web site:

Team Members:

• Adam Stack - bigstack80@knights.ucf.edu - web page
• Horia Ionescu - ionescu@knights.ucf.edu - web page
• Remo Gutierrez - Remog@knights.ucf.edu - web page
• Michael Paulsen - Michael.Paulsen@ucf.edu - web page
• Tyler Harbin-Giuntoli - Tyler@knights.ucf.edu - web page
• Ross Pape - ross.pape@knights.ucf.edu - web page

Contents of this Document

1. Introduction:

Overall Objective for Software Test Activity

Reference Documents

2. Description of Test Environment
3. Overall Stopping Criteria
4. Description of Individual Test Cases

SECTION 1: Introduction

• Overall Objective for Software Test Activity:
• The terminal goal of our test activity is to deliver a finished product polished to the point in which any remaining bugs (if any) do not obstruct the end-user’s ability to enjoy the finished product from beginning to end. This will be achieved through careful dissection of the product into distinct parts on which we will run rigorous and repeated test exercises to ensure that any faults commonly experienced can be identified and corrected.

Reference Documents:

• Concept of Operations
• Project Management Plan
• Software Requirement Specification

SECTION 2: Description of Test Environment

The software is being developed inside the Unity SDK across various versions of Windows and Mac OSX. The application itself is being developed for the Android OS, but will be tested in an emulated Android environment within the Unity SDK as well as natively tested on a Galaxy S3, Galaxy S4, HTC One-X+ and an LG Optimus G; the same environment that the application will run on. While the emulated Android environment will technically run less efficiently than the native environment, it should not introduce any new problems, and the native environment testing will be in place to confirm that. Michael Paulsen will be the Testing Lead, assisted by Horica Ionescu.

SECTION 3: Stopping Criteria

The test process will proceed in the following manner:

Errors discovered during testing will be organized into three categories: cosmetic, mechanical, and fatal. A cosmetic error describes an issue that affects the way the game looks, but otherwise does not impede the ability for the user to progress or enjoy the product as intended. A mechanical error is a fault in the way the product works; this could include unintended occurrences with the physics, AI, or menus. A mechanical fault may or may not impede progress in an unintended way, however the application will continue to function. Finally, a fatal error is a fault that causes the application to terminate abruptly or otherwise prevent the user from continuing the experience.

Each section of the application will be tested by no fewer than two developers. Errors of a cosmetic or mechanical nature will be recorded throughout the process until the section has been completed or a fatal error is reached. In the event of a fatal error, the compiled list of errors will be sent back to the lead developer for evaluation. If no fatal errors are discovered within a particular section, the test of that section will be repeated an additional 4 times. If no fatal error occurs, any cosmetic or mechanical errors will be recorded and submitted to the lead developer, but testing will continue onto the next section.

Errors will be addressed in order of importance with fatal being the most important, and cosmetic being the least. The product will be considered ready for delivery when no known fatal or mechanical errors remain.

SECTION 4: Description of Individual Test Cases

Character leveling

• A character should be able to level up and distribute experience points.
• Test Description: To test a tester would need to level up a character multiple levels without having any problems with the leveling system.
• Test Conditions: This test will take place within the game.

Combat system

• Test Description: The combat system should be fair and challenging.
• Expected Results: This should be tested as we are coding to make sure hit points are distributed evenly. It also will need to be tested in the finished product as a player tester.
• Expected Results: The combat system should be fair and enjoyable.

Saving

• Test Objective: The system should allow the user to save the game.
• Test Conditions: This will need to be tested on a once the menu system and game figures are created.

Character selection and customization.

• Test Description: The game needs to allow the user to make customizations to his character through the in game menu.
• Test Conditions: This will need to be tested on a once the menu system and game figures are created.
• Expected Results: Characters should be customized without any errors.

Template created by G. Walton (GWalton@mail.ucf.edu) on March 28, 1999 and last modified on August 15, 2000.

This page last modified by Adam Stack (bigstack80@knights.ucf.edu ) on 09/18/2014