Game Functional Testing

Game Functional Testing

Functional testing of a game is not "playing and finding bugs." It is systematic verification that each game scenario works according to the Game Design Document: mechanics, UI flow, inventory, progression, saves, network interactions. The difference between "we played it, everything works" and full functional testing usually becomes apparent at release when players report scenarios that the team never intentionally tested.

What functional testing really covers

A typical real-world example: a shooter with a crafting system. The team manually checked the main flow — opened inventory, crafted an item, closed it. Everything works. At release, it turned out that if you craft an item when inventory is full (99/100 slots) and the crafted item occupies the last slot while also being a craft ingredient — the slot counter goes to -1, and the entire session breaks. This is a classic edge case at the intersection of two mechanics, which is only found through systematic test-case approach, not free exploration.

Functional testing in game development covers several layers:

Gameplay mechanics — each mechanic is tested in isolation, then in combination with others. Does the jump work? Jump on a moving platform? Jump while taking damage? Jump at zero HP?

UI and navigation — all screens, all transitions, all element states (disabled, loading, error). Special attention to scene transitions: if the player clicks "to main menu" while the match is ending, both events may try LoadScene simultaneously.

Save and load — the most underestimated area. Saving mid-cutscene, loading on a new device, data migration on version update. In Unity, PlayerPrefs and JSON serializers have no built-in version migration — when data structure changes, old saves simply don't parse and the game crashes without clear error.

Network scenarios for multiplayer: packet loss, player disconnect mid-match, reconnect, state desynchronization.

Tools and approaches

For automated functional testing in Unity, we use Unity Test Framework (UTF) in Play Mode Tests. UTF allows writing tests that run inside a game session with full access to scene components. A typical crafting mechanic test looks like: create inventory with predefined state via fixture, call CraftingSystem.TryCraft(recipeId), assert on inventory state and returned result.

For UI testing, we use combination of UTF + Unity UI Test Helpers or custom wrappers over EventSystem.RaiseEvent. Manual UI testing via Selenium or Playwright doesn't apply to game interfaces — we need tools that understand Canvas, EventSystem, and InputSystem from Unity.

For mobile platforms — Unity Remote for quick device verification without full build, and real devices (not just emulators) to verify platform specifics: gestures, Android back-button, call interruptions.

Defects are fixed in a tracker (Jira, YouTrack) with mandatory fields: reproduction steps, expected result, actual result, build version, device, screenshot or video. Without this, bug reproduction on the developer side takes 3–5 times longer.

How the process is structured

Testing starts before build delivery: audit GDD for scenario completeness, create test plan and test cases. A good test case is tied to a specific requirement from documentation — this allows tracking coverage.

Smoke-testing of new build: 15–20 key cases that verify nothing fundamental is broken. If smoke passes — full regression run. New feature functional testing — separately, with focus on integration cases.

Final stage before release — certification testing: verification against platform requirements (Steam, App Store, Google Play, consoles — each has their own checklists). This is technically also functional testing, just with external criteria.

Cost is calculated after analysis of GDD, number of test cases, and required coverage.