Skip to content

UGS Test Plan

harland-jensen edited this page Oct 4, 2022 · 3 revisions

1. Introduction

1.1 Test Objectives

The system integration tests of the UGS for the Atlantis Sinks game should validate design choices from the developers’ and users’ perspective on all affected aspects of the existing game.
Tests should address:

  • the current operation of the game
  • the independent performance of the added modules
  • the dependent performance of the added modules
  • the added functionality or capability of the new feature

The testing should validate the complete system operation with existing and appended components together. The test conclusion should provide the team with a high level of confidence that the program will work according to user requirements.

1.2 Scope of Testing

The system integration tests will consist of JUnit and user testing of all UGS classes in Atlantis Sinks to validate functionality and interaction design decisions. Direct and indirect testing of other dependent game classes and functions will be included in the overall integration testing process.
Other independent game classes and functions will not be included in the integration tests.

1.3 System Overview

Atlantis Sinks is a RTS tower defence style single player game and is based on the LibGDX framework and developed in Java programming language. Atlantis Sinks uses entities, components, events, services, and resources as key aspects of its game engine architecture to make the development process and interaction easy.

1.4 References

2. Approach

2.1 Assumptions/Constraints

2.1.1 Assumptions

  • Other game branches do not modify the current branch classes
  • Key aspects and interface architecture of the main game are not changed
  • Each successful build of the team's branch will have passed all unit testing before integration testing will commence with main branch

2.1.2 Constraints

  • Time complexity of going through all the test procedures for each modification to UGS may be infeasible

2.2 Coverage

Test coverage will be outlined as:

  • A table of testable requirements and the test cases addressing them
  • A table of test necessity and the accompanied test case for all created tests If the outlined coverage levels are not met, software may not be released or further conversations and investigations will be conducted to ensure code and documentation are adequate.

2.2.1 Software Components

Team 7's classes and methods of Atlantis Sinks along with all overlapping main interfacing components necessary to completely test the integrated featureset.

2.2.2 Requirements

All agreed on user requirements from the design test plan will be tested.

2.2.3 Code Coverage

The coverage of all JUnit test programs will be assessed using SonarCloud and test code analysis. Tests should cover at least 80% of the functionality of the program.

2.3 Test Tools

  • JUnit Testing (Automated Software Testing)
  • SonarCloud (Automated Software Testing Analysis)
  • Interviews (Software User Testing)
  • Peer-to-peer Conversations (Software Peer User Testing)

3. Plan

3.1 Test Team

The following team members will be actively apart of managing and conducting the software integration testing:

Name Title Responsibilities
Jonathan Allen Software Developer Design and execute test cases for the UGS classes of Atlantis Sinks following the test plan appropriately.
Harland Jensen Software Developer Design and execute test cases for the UGS classes of Atlantis Sinks following the test plan appropriately.

3.2 Team Reviews

Team reviews will also be conducted for all test cases created by the team. Team reviews include theoretical and practical reviews of the test plan, unit tests, test coverage, and test results. Team reviews will be held at the end of each sprint or after all major test integrations.

3.3 Major Tasks and Deliverables

Task Assignee Deliverable
UGS automated tests Harland Jensen JUnit tests for UGS classes
UGS integration tests (automated) Jonathan Allen JUnit tests for UGS classes integrated into main branch (testing collaboration of game features)

4. Tested Features

4.1 Sprint 3

4.1.1 UGS classes

4.1.1.1 Creation of UGS

  • UGS can be created
  • UGS correctly stores state of entities
  • UGS correctly stores state of world

4.1.1.2 UGS state deletion

  • Entities can be removed from the UGS
  • Tile types can be changed from the UGS

4.1.1.3 UGS update

  • UGS can be updated with new information

4.1.2 Integration tests with dependent Atlantis Sinks classes

4.1.2.1 Integration of UGS with main character

  • Appropriate testing must be present to test the UGS' integration with the main character feature

4.1.2.2 Integration of UGS with enemies

  • Appropriate testing must be present to test the UGS' enemy integration

4.1.2.3 Integration of UGS with structures

  • Appropriate testing must be present to test the UGS' structures integration

4.1.2.4 Integration of UGS with the map

  • Appropriate testing must be present to test the UGS' map integration

5. Untested Features

5.1 Independent Game Features

  • Other game features of Atlantis Sinks that have no direct interaction with the UGS.

6. Testing Procedures

6.1 Test Execution

6.1.1 Test Cases

For all requirements and features, the tester will perform JUnit tests and user testing as defined previously. Each test performed will provide the tester with data regarding the result of the test and the expected result of the test, for unit tests and user tests. The summed results of the tests are then evaluated and analyzed. The passed tests are noted, and the failed tests or associated classes are revised.

6.1.2 Testing Order

The tests will be run in a predefined order relative to the Gradle build order. With each version and build of the game the tests will be performed as follows:

6.1.2.1 Sprint 2

UGS class features:
  1. UGS creation
  2. UGS state deletion
  3. UGS update
Integration of UGS:
  1. Main Character
  2. Enemies
  3. Structures
  4. Map

6.2 Pass Criteria

To pass the tests:

  • Unit tests must have a coverage of greater than 60%
  • All unit tests must pass without exception
  • Feature must be tested by at least 10 different people
  • User testing must pass with greater than 70% acceptance of feature
  • Integration tests must not break main branch
  • Integration tests must result in 99.99% integration of UGS feature without disrupting other game features

6.3 Defect Management

All defects found by the test procedure must be recorded and addressed. Defects will be labelled from low, medium, high, to critical.

Level Description
Low Defect hinders the optimal performance of the feature
Medium Defect hinders the performance of the feature
High Defect breaks the functionality of the feature branch
Critical Defect breaks the functionality of the main branch

Critical, high, and medium defects must be addressed immediately by team member leading the tests of the defective feature. Low defects can be reviewed in the team review and addressed at a later time.

Table of Contents

Home

How to Play

Introduction

Game Features

Main Character

Enemies
The Final Boss

Landscape Objects

Shop
Inventory
Achievements
Camera

Crystal

Infrastructure

Audio

User Interfaces Across All Pages
Juicy UI
User Interfaces Buildings
Guidebook
[Resource Management](Resource-Management)
Map
Day and Night Cycle
Unified Grid System (UGS)
Polishing

Game Engine

Getting Started

Entities and Components

Service Locator

Loading Resources

Logging

Unit Testing

Debug Terminal

Input Handling

UI

Animations

Audio

AI

Physics

Game Screens and Areas

Terrain

Concurrency & Threading

Settings

Troubleshooting

MacOS Setup Guide

Clone this wiki locally