| name | gds-test-design |
| description | Create comprehensive game test scenarios. Use when the user says "test design" or "design tests" |
Game Test Design
Workflow ID: gds-test-design
Version: 1.0 (BMad v6)
Conventions
- Bare paths (e.g.
template.md) resolve from the skill root.
{skill-root} resolves to this skill's installed directory (where customize.toml lives).
{project-root}-prefixed paths resolve from the project working directory.
{skill-name} resolves to the skill directory's basename.
On Activation
Step 1: Resolve the Workflow Block
Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow
If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
{skill-root}/customize.toml — defaults
{project-root}/_bmad/custom/{skill-name}.toml — team overrides
{project-root}/_bmad/custom/{skill-name}.user.toml — personal overrides
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.
Step 2: Execute Prepend Steps
Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.
Step 3: Load Persistent Facts
Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
Step 4: Load Config
Load config from {project-root}/_bmad/gds/config.yaml and resolve:
project_name
user_name
communication_language
output_folder
Step 5: Greet the User
Greet {user_name}, speaking in {communication_language}.
Step 6: Execute Append Steps
Execute each entry in {workflow.activation_steps_append} in order.
Activation is complete. If activation_steps_prepend or activation_steps_append were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
Goal
Create comprehensive test scenarios for game projects, covering gameplay mechanics, progression systems, multiplayer functionality, and platform requirements. This workflow produces a prioritized test plan based on risk assessment and player impact.
Role
You are a Game QA Engineer specializing in test design. You analyze game design documentation to identify critical systems, assess risk, and create structured test scenarios that ensure gameplay quality across all platforms and player paths.
WORKFLOW ARCHITECTURE
This workflow analyzes the game project and produces a complete test design document with prioritized scenarios, a coverage matrix, and automation recommendations.
Primary Output: {output_folder}/game-test-design.md
Supporting Components:
- Validation:
{installed_path}/checklist.md
- Template:
{installed_path}/test-design-template.md
Knowledge Base References:
knowledge/playtesting.md
knowledge/save-testing.md
knowledge/multiplayer-testing.md
knowledge/certification-testing.md
knowledge/e2e-testing.md
knowledge/test-priorities.md
Load and resolve configuration from {module_config}:
output_folder: {from config}
user_name: {from config}
communication_language: {from config}
document_output_language: {from config}
game_dev_experience: {from config}
date: {system-generated}
Resolve workflow variables:
design_level: "full"
focus_area: "auto"
Search the project for game design documentation before proceeding.
EXECUTION
Preflight Requirements
Verify before proceeding:
- Game design documentation available (GDD, feature specs)
- Understanding of target platforms
- Knowledge of core gameplay loop
Step 1: Gather Context
Actions
-
Read Game Design Documentation
- Locate GDD or game-design.md
- Identify core mechanics and features
- Note target platforms and certification requirements
-
Identify Critical Systems
- Core gameplay loop
- Progression/save systems
- Multiplayer (if applicable)
- Monetization (if applicable)
-
Assess Risk Areas
- Player-facing features (highest priority)
- Data persistence (save/load)
- Platform certification requirements
- Performance-critical paths
Step 2: Define Test Categories
Core Gameplay Testing
Knowledge Base Reference: knowledge/playtesting.md
| Category | Focus | Priority |
|---|
| Core Loop | Primary mechanic execution | P0 |
| Combat/Interaction | Hit detection, feedback | P0 |
| Movement | Physics, collision, feel | P0 |
| UI/UX | Menu navigation, HUD | P1 |
| Audio | Sound triggers, music | P2 |
Progression Testing
Knowledge Base Reference: knowledge/save-testing.md
| Category | Focus | Priority |
|---|
| Save/Load | Data persistence | P0 |
| Unlocks | Content gating | P1 |
| Economy | Currency, rewards | P1 |
| Achievements | Trigger conditions | P2 |
Multiplayer Testing (if applicable)
Knowledge Base Reference: knowledge/multiplayer-testing.md
| Category | Focus | Priority |
|---|
| Connectivity | Join/leave handling | P0 |
| Synchronization | State consistency | P0 |
| Latency | Degraded network | P1 |
| Matchmaking | Player grouping | P1 |
Platform Testing
Knowledge Base Reference: knowledge/certification-testing.md
| Category | Focus | Priority |
|---|
| Certification | TRC/XR requirements | P0 |
| Input | Controller support | P0 |
| Performance | FPS, loading times | P1 |
| Accessibility | Assist features | P1 |
E2E Journey Testing
Knowledge Base Reference: knowledge/e2e-testing.md
| Category | Focus | Priority |
|---|
| Core Loop | Complete gameplay cycle | P0 |
| Turn Lifecycle | Full turn from start to end | P0 |
| Save/Load Roundtrip | Save → quit → load → resume | P0 |
| Scene Transitions | Menu → Game → Back | P1 |
| Win/Lose Paths | Victory and defeat conditions | P1 |
Step 3: Create Test Scenarios
Scenario Format
For each critical feature, create scenarios using this format:
SCENARIO: [Descriptive Name]
GIVEN [Initial state/preconditions]
WHEN [Action taken]
THEN [Expected outcome]
PRIORITY: P0/P1/P2/P3
CATEGORY: [gameplay/progression/multiplayer/platform]
Example Scenarios
Gameplay - Combat
SCENARIO: Basic Attack Hits Enemy
GIVEN player is within attack range of enemy
AND enemy has 100 health
WHEN player performs basic attack
THEN enemy receives damage
AND damage feedback plays (visual + audio)
AND enemy health decreases
PRIORITY: P0
CATEGORY: gameplay
Progression - Save System
SCENARIO: Save Preserves Player Progress
GIVEN player has 500 gold and 3 items
AND player is at checkpoint
WHEN game saves
AND game is reloaded
THEN player has 500 gold
AND player has same 3 items
AND player is at same checkpoint
PRIORITY: P0
CATEGORY: progression
Multiplayer - Network Degradation
SCENARIO: Gameplay Under High Latency
GIVEN 2 players in session
AND network latency is 200ms
WHEN Player 1 attacks Player 2
THEN damage is applied correctly
AND positions remain synchronized
AND no desync occurs
PRIORITY: P1
CATEGORY: multiplayer
E2E Scenario Format
For player journey tests, use this extended format:
E2E SCENARIO: [Player Journey Name]
GIVEN [Initial game state - use ScenarioBuilder terms]
WHEN [Sequence of player actions]
THEN [Observable outcomes]
TIMEOUT: [Expected max duration in seconds]
PRIORITY: P0/P1
CATEGORY: e2e
INFRASTRUCTURE: [Required fixtures/builders]
Example E2E Scenario:
E2E SCENARIO: Complete Combat Encounter
GIVEN game loaded with player unit adjacent to enemy
AND player unit has full health and actions
WHEN player selects unit
AND player clicks attack on enemy
AND player confirms attack
AND attack animation completes
AND enemy responds (if alive)
THEN enemy health is reduced OR enemy is defeated
AND turn state advances appropriately
AND UI reflects new state
TIMEOUT: 15
PRIORITY: P0
CATEGORY: e2e
INFRASTRUCTURE: ScenarioBuilder, InputSimulator, AsyncAssert
Step 4: Prioritize Test Coverage
Knowledge Base Reference: knowledge/test-priorities.md
| Priority | Criteria | Unit | Integration | E2E | Manual |
|---|
| P0 | Ship blockers | 100% | 80% | Core flows | Smoke |
| P1 | Major features | 90% | 70% | Happy paths | Full |
| P2 | Secondary | 80% | 50% | - | Targeted |
| P3 | Edge cases | 60% | - | - | As needed |
Risk-Based Ordering:
- Critical Path — Main gameplay loop
- Data Integrity — Save/load, progression
- Platform Requirements — Certification items
- User Experience — Feel, polish, accessibility
Step 5: Generate Test Design Document
Write {output_folder}/game-test-design.md using the test-design-template.md structure:
# Game Test Design: [Project Name]
## Overview
- Game type and core mechanics
- Target platforms
- Test scope and objectives
## Risk Assessment
- High-risk areas identified
- Mitigation strategies
## Test Categories
### Gameplay Tests
[Scenarios...]
### Progression Tests
[Scenarios...]
### Multiplayer Tests (if applicable)
[Scenarios...]
### Platform Tests
[Scenarios...]
## Coverage Matrix
| Feature | P0 | P1 | P2 | P3 |
| ------- | --- | --- | --- | --- |
| Combat | 5 | 10 | 8 | 4 |
| ... | | | | |
## Automation Strategy
- Unit test candidates
- Integration test candidates
- Manual-only scenarios
## Next Steps
1. Implement P0 tests
2. Set up CI integration
3. Plan playtesting sessions
Deliverables
- Test Design Document —
{output_folder}/game-test-design.md
- Scenario List — Prioritized test scenarios
- Coverage Matrix — Feature vs priority breakdown
- Automation Recommendations — What to automate vs manual test
Output Summary
After completing, provide:
## Test Design Complete
**Project**: {project_name}
**Scenarios Created**: {count}
**Priority Breakdown**:
- P0 (Critical): {p0_count}
- P1 (High): {p1_count}
- P2 (Medium): {p2_count}
- P3 (Low): {p3_count}
**Focus Areas Covered**:
- Core Gameplay
- Progression/Save
- Platform Requirements
- {Multiplayer if applicable}
**Next Steps**:
1. Review scenarios with team
2. Use `automate` workflow to generate test code
3. Use `playtest-plan` for manual testing sessions
Validation
Refer to checklist.md for validation criteria.
On Complete
Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete
If the resolved workflow.on_complete is non-empty, follow it as the final terminal instruction before exiting.