Master Test Plan

1.1 Purpose

This Master Test Plan (MTP) outlines the comprehensive strategy, objectives, scope, approach, environment, resources, and schedule for the testing activities of the Galactic Fruit game. It serves as the primary agreement between the Quality Assurance team and developer regarding what will be tested, how quality will be assured for the pre-release build, and the criteria for release readiness. Since formal feature documentation is limited, this plan also defines the exploratory

1.3 Acronyms

• FPS: Frames Per Second
• UI/UX: User Interface / User Experience
• SUT: System Under Test
• GF: Galactic Fruit
• PC: Personal Computer

1.4 References

• Steam Store Page
• In-game Operations Manual
• Informal Communication With Developer
• Exploratory Notes

2.1 Assumptions and Constraints

2.2 Coverage

Test coverage will be measured by the execution of test cases against identified requirements and features. In the event that coverage levels are not met due to time constraints, the QA Lead will determine if the actual levels are adequate based on risk assessment.

Coverage targets include:

• 100% of Critical Path (A → B progression) features.
• 100% of UI/Menu functionality (Start, Options, Quit).
• 100% of terminal feature coverage.
• 100% of minigame feature coverage.

2.3 Test Types

The following types of testing will be performed during system integration testing:

• Functional Testing: Execution of test cases based on gameplay mechanics (e.g., movement, interaction) to ensure they behave as intended.
• Regression Testing: Re-testing previously validated functionality after a new build is deployed to ensure no new defects have been introduced.
• Exploratory Testing: Testing the game without a specific plan to identify unexpected issues and validate the overall gameplay experience.
• Smoke Testing: Testing the game to ensure it is stable and free of critical defects.
• Usability Testing: Ensuring the game is easy to use and navigate.
• Recovery Testing: Ensuring the game can handle unexpected closures (Alt+F4) without corrupting save data.
• Performance Testing: Ensuring the game runs at a minimum of 60 FPS on our spec hardware.

2.4 Test Data

To perform system integration testing, test data will be supplied from two sources:

• Fresh Saves: New game states created at the start of each test cycle.
• Dev Tools: Tools provided by the developer to jump specifically to late-game sections without playing through the full loop using the [F3] dev tool menu.

2.5 Test Basis Derivation Strategy

In the absence of formal requirement specifications, the Test Basis and subsequent Test Conditions will be derived primarily from Exploratory Notes. This approach allows the QA team to reverse-engineer requirements based on the current state of the application and developer intent.

2.6 Automation Strategy

To optimize testing efficiency, a custom automation framework utilizing nut.js has been integrated. This framework is designed to handle basic smoke testing, unique repetitive scenarios (such as terminal commands and menu navigation), and core progression tests (including the intro sequence and stage transitions).

Unlike traditional integration tests, this framework operates as a "Black Box" tool with a "Human-in-the-loop" design, relying on the player to act as the test oracle.

Limitations:

• Game window must be in focus and resolution matched (1920x1080).
• Tests are fragile to UI layout changes.
• Cannot be run "headless" or in background CI/CD pipelines.

3.1 Test Team

3.2 Major Tasks and Deliverables

3.3 Environmental Needs

WIP

6.1 Test Execution

For each requirement, business process, or system feature to be tested, the tester will execute a set of pre-defined test cases. Each test case will have a series of actions and expected results. As each action is performed, the results are evaluated.

• If the observed results are equal to the expected results, the test case is marked as PASS .
• If the observed results differ, the test case is marked as FAIL , and a defect is logged.

6.2 Pass/Fail Criteria

To pass the system integration test, the following criteria must be met:

• All core gameplay loops are functional.
• No "Critical" (S1) or "High" (S2) defects remain open.
• The game launches, runs, and closes without crashing.
• Performance maintains a minimum of 60 FPS on our spec hardware.

6.3 Suspension Criteria

Testing will be suspended if any of the following occur:

• Build instability causes crashes during a test case over 25% of the time.
• A critical progression blocker prevents access to the majority of test cases.
• The test environment (Steam/Hardware) becomes unavailable.

6.4 Defect Management

Defects will be tracked using GitHub Issues. Each defect report must be written clearly and unambiguously.

• Title: A concise, descriptive summary of the problem (what is wrong, where it occurs).
• Description: A clear explanation of the defect, including its impact on gameplay or test objectives.
• Preconditions: Any required setup such as game version, platform/OS, etc.
• Steps to Reproduce: Numbered, detailed steps to reliably reproduce the defect from a known state.
• Expected Result: The correct behavior as per requirements or design.
• Actual Result: The observed incorrect behavior.
• Attachments: Screenshots or video evidence demonstrating the defect.
• Additional Information: Any relevant logs, patterns, or workarounds.
• Severity and Priority: Assigned based on impact and urgency (see below).

6.5 Test Case Requirements

All test cases must follow a standardized structure to ensure consistency, clarity, and full traceability across the testing effort. Each test case must include the following required components:

• ID: A unique identifier following the project’s naming conventions (e.g., TC-SMOKE-002).
• Name: A clear, concise title summarizing the scenario being validated.
• Description: A high-level explanation of the scenario, feature, or user flow under test.
• Test Objective: The specific purpose of the test case, stating what functionality or behavior is being validated.
• Priority: Business or risk-based importance (e.g., Critical, High, Medium, Low).
• Type: The classification of the test (e.g., Smoke, Regression, Functional).
• Author & Dates: Metadata including test case creator, creation date, and last modified date.
• Preconditions: Required setup steps, system states, or test environment conditions that must be true before execution.
• Test Data: Any structured values needed to execute the scenario (e.g., player name, difficulty, inventory items).
• Environment: The target environment(s) for execution (e.g., Windows, console builds, staging server).
• Steps: A numbered, ordered list of user actions paired with the expected result for each step. (Each step must define “action” and “expected.”)
• Postconditions: The expected end state of the game or system once the test case completes successfully.
• Estimated Execution Time: Approximate time needed to execute the test manually.
• Tags: Keywords supporting filtering, reporting, grouping, and suite organization (e.g., smoke, navigation, critical-path).