Test Plan¶
Document Data¶
Document number: TT-001-EXMPL
Prepared by:
- Kiss Pista István, tester
- Fekete Péter, tester
- Metil Ibolya, tester
Version history:
| Version | Release date | Description |
|---|---|---|
| 1.0 | 2024.06.30 | Initial release of the document |
Context of the Testing Task¶
This document contains the test plan for the Unlucky project, chosen by team XX in the XXXX/YYYY academic year “Basics of Testing” course.
The Unlucky application is a LibGDX Android RPG game with a turn-based combat system based on RNG (random number generator). While RNG is often disliked in games, this project’s core concept is built around RNG. In battle, everything—from attacks to magical items to movement—is based on RNG.
The player fights various monsters on differently themed maps. Currently, three worlds are available, each with 10+ levels. On each map, the player must defeat monsters and find a star tile to complete the level. Monsters can drop items that either strengthen the player or can be sold.
The combat system is turn-based. The player receives four randomly generated moves, each color representing a different type of action. The player also has access to special moves, chosen from a menu, which enhance attacks or affect enemies. There is also a very small chance for the player to escape from battle.
The purpose of testing is to support quality improvement by finding defects and evaluating the gameplay experience. To achieve this goal, we apply static testing and usability testing.
The version under test is 1.0, released on 2018.07.03.
The static tests will focus on the source code of the Unlucky core and desktop modules, performing static code analysis on these units.
The usability test will focus on the Desktop version’s user interface, evaluating the end-user experience. No separate documentation is available, but the README files with screenshots on the project page provide some guidance.
Assumptions and Constraints¶
We assume that the release packages published on the Unlucky project’s release page are installable and functional. The developer has made both the working code and its source code available, with build requirements described in the README. We further assume that required versions are accessible, downloadable, and Gradle configurations are properly set.
Only the desktop version will be tested; the Android version is excluded.
Stakeholders¶
- Testing team: plans and executes the testing
- Volunteers involved in testing: evaluate gameplay experience; their feedback will be collected via questionnaires
- Instructor: defines requirements and evaluates performance
- Developer: receives feedback from tests and can use it to develop ideas for improving gameplay
Communication¶
For official communication, we use the email addresses provided by the Institute of Informatics. Through this channel we communicate with the instructor.
Additionally, the Coospace forum for the course is considered an official communication channel, but only public information is shared there. Private information is communicated exclusively via institute-provided email.
Project communication may also occur in person or through online meetings via the Discord XXXX channel. Meeting minutes are recorded for each meeting.
Risk Management¶
Risk mitigation options for project risks:
- Few or no tasks scheduled mid-project or at the end, to allow catching up on delays
- Frequent meetings to avoid misunderstandings
Risk mitigation options for product risks:
- Use of backup devices in case of failure
- Frequent backups
- Regularly pushing local buffers
Note: Due to the small number of risks, both project and product risks are shown in the same risk matrix.
Test Approach¶
Test Levels¶
- Static testing: performed at module level
- Usability testing: performed at system level
Test Types¶
We conduct two types of testing:
Static code analysis (static testing)
Usability testing (black-box type)
Both are non-functional tests.
Test Techniques¶
- For static testing: source code inspection with appropriate tools
- For usability testing: defining user stories, preparing detailed acceptance criteria, and designing test scenarios and questionnaires
Volunteers of different ages and interests execute the acceptance criteria through scenarios. Their questionnaire responses are collected and evaluated.
Test Deliverables¶
- The test plan
- User story description with acceptance criteria and detailed scenarios for usability testing
- Questionnaires and collected responses
- Processed results and conclusions
- Selected feature set for static code analysis
- Report of highlighted rule violations
- Report of general rule violations
- List of violations in serialized form (e.g., XML)
- Intermediate and final reports
Entry and Exit Criteria¶
Static testing entry criteria:
- Test plan approval
- Availability of Java runtime and working Gradle
- Availability of a text editor (e.g., GitLab editor, Visual Studio Code with Markdown plugins, etc.)
- If the software does not build out-of-the-box: creation of a compilable fork
- Setup of Eclipse or JetBrains IDE with SpotBugs (Eclipse) plugin
Static testing exit criteria:
- At least 50 (preferably more) analyzed rule violations, documented in the required reports
Usability testing entry criteria:
- Test plan approval
- The game runs successfully
- Scenarios and questionnaires based on acceptance criteria are ready
- Volunteer groups are organized
Usability testing exit criteria:
- At least 5 scenarios with completed questionnaires
- At least 20 users completed the questionnaires
- Results are processed, deliverables are prepared
Test Environment¶
For usability testing:
- Standard desktop (Windows/MacOS/Linux), no special hardware requirements
- Java 8 runtime
- Gradle
- Google Forms
For static testing:
- Standard desktop (Windows/MacOS/Linux), no special hardware requirements
- Java 8
- Gradle
- Eclipse or JetBrains IDE
- SpotBugs or IntelliJ IDEA’s built-in analyzer
- CheckStyle
Schedule¶
The project schedule is shown in the following Gantt chart:
Responsibilities¶
| Name | Responsibility |
|---|---|
| Kiss Pista István | XXXXXXX |
| Fekete Péter | YYYYYYY |
| Metil Ibolya | ZZZZZZZ |
Approver¶
Approved today:
Date: 2024.06.30
Approver: Dr. Henrik, Instructor