-
Notifications
You must be signed in to change notification settings - Fork 0
Software Test Plan (Team 7)
The system integration tests of the infrastructure classes of 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 integration of the new feature with the existing infrastructure
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.
The system integration tests will consist of JUnit and user testing of all infrastructure 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.
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.
- 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
- Time complexity of going through all the test procedures for each modification to infrastructure may be infeasible
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.
Team 7's classes and methods of Atlantis Sinks along with all overlapping main interfacing components necessary to completely test the integrated featureset.
All agreed on user requirements from the design test plan will be tested.
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.
- JUnit Testing (Automated Software Testing)
- SonarCloud (Automated Software Testing Analysis)
- Interviews (Software User Testing)
- Peer-to-peer Conversations (Software Peer User Testing)
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 infrastructure classes of Atlantis Sinks following the test plan appropriately. |
| Harland Jensen | Software Developer | Design and execute test cases for the infrastructure classes of Atlantis Sinks following the test plan appropriately. |
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.
| Task | Assignee | Deliverable |
|---|---|---|
| StructureFactory automated tests | Jonathan Allen | JUnit tests for StructureFactory |
| StructureService automated tests | Jonathan Allen | JUnit tests for StructureService |
| Structure Components automated tests | Harland Jensen | JUnit tests for structure components |
| Infrastructure integration tests (automated) | Harland Jensen | JUnit tests for infrastructure classes integrated into main branch (testing collaboration of game features) |
| Infrastructure integration tests (user testing) | Jonathan Allen Harland Jensen | User testing for all infrastructure classes (focusing on gameplay operations/reliability/functionality) |
- Structures can be created and added to the entities list
- All structures have a unique name
- Structures are rendered by the game engine
- Structures can be deleted and removed from the entities list
- Structures are disposed of correctly without memory leakage
- Structures must be able to be placed on the map
- Structures must not be able to be built on other game entities
- Structures should not be able to be placed on non-buildable tiles
- Structures should conform to the world grid system
- Components for different types of structure should be tested
- Different structures with different added components must act different and provide different functionality
- A structure entity must be able to be selected
- A structure entity must be able to change specific descriptive attributes upon request
- A structure entity must be able to provide specific descriptive attributes upon request
- Appropriate testing must be present to test the structures side of building UI integration
- Appropriate testing must be present to test the structures side of enemy integration
- Appropriate testing must be present to test the structures side of shop integration
- Other game features of Atlantis Sinks that have no direct interaction with infrastructure classes
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.
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:
- Structure creation
- Structure deletion
- Integrated placement of structures
- Structure components
- Obtaining attributes of structures
- Building UI integration
- Enemies integration
- Shop integration
- 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 structure feature without disrupting other game features
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.