feat(analytics): Implement Analytics Dashboard and Token Management

This commit is contained in:
Michael committed 2026-01-20 13:49:24 +01:00
1 parent b38f082d6e
commit f8ddb44e38
822 files changed
+132545 -51

No files matched your search

@@ -0,0 +1,93 @@
# Game Test Automation - Validation Checklist
---
## Prerequisites
- [ ] Test framework initialized
- [ ] Game engine detected
- [ ] Source code accessible
- [ ] Test scenarios available (optional)
---
## Analysis
- [ ] Testable systems identified
- [ ] Existing tests located
- [ ] Test patterns understood
- [ ] Coverage gaps identified
---
## Unit Tests
- [ ] Tests follow engine conventions
- [ ] Arrange-Act-Assert pattern used
- [ ] Setup/teardown implemented
- [ ] Parameterized tests where appropriate
- [ ] No external dependencies
- [ ] Tests are deterministic
---
## Integration Tests
- [ ] Scene/level tests created
- [ ] Component interaction tested
- [ ] Async handling correct (await/yield)
- [ ] Cleanup prevents leaks
- [ ] Tests run independently
---
## Smoke Tests
- [ ] Critical path covered
- [ ] Game launch test exists
- [ ] Core loop test exists
- [ ] Save/load test exists
- [ ] Tests complete quickly (< 5 min total)
---
## Code Quality
- [ ] Tests compile without errors
- [ ] No hardcoded values
- [ ] Assertions have messages
- [ ] Test names are descriptive
- [ ] No duplicate test logic
---
## Generated Files
- [ ] Files placed in correct directories
- [ ] Naming conventions followed
- [ ] Engine-specific syntax correct
- [ ] Imports/includes complete
---
## Documentation
- [ ] Automation summary created
- [ ] Test distribution documented
- [ ] Files listed
- [ ] Next steps provided
---
## Completion Criteria
- [ ] All requested tests generated
- [ ] Tests pass initial run
- [ ] No orphan objects after tests
- [ ] Summary report created
---
**Completed by:** {name}
**Date:** {date}
**Tests Generated:** {count}
@@ -0,0 +1,317 @@
<!-- Powered by BMAD-CORE™ -->
# Game Test Automation
**Workflow ID**: `_bmad/bmgd/gametest/automate`
**Version**: 1.0 (BMad v6)
---
## Overview
Generate automated test code for game projects based on test design scenarios or by analyzing existing game code. Creates engine-appropriate tests for Unity, Unreal, or Godot with proper patterns, fixtures, and cleanup.
---
## Preflight Requirements
- ✅ Test framework already initialized (run `framework` workflow first)
- ✅ Test scenarios defined (from `test-design` or ad-hoc)
- ✅ Game code accessible for analysis
---
## Step 1: Analyze Codebase
### Actions
1. **Detect Game Engine**
- Check for engine-specific project files
- Load appropriate knowledge fragments
2. **Identify Testable Systems**
- Pure logic classes (calculators, managers)
- State machines (AI, gameplay)
- Data structures (inventory, save data)
3. **Locate Existing Tests**
- Find test directory structure
- Identify test patterns already in use
- Check for test helpers/fixtures
---
## Step 2: Generate Unit Tests
### Unity (C#)
**Knowledge Base Reference**: `knowledge/unity-testing.md`
```csharp
using NUnit.Framework;
[TestFixture]
public class {ClassName}Tests
{
private {ClassName} _sut; // System Under Test
[SetUp]
public void Setup()
{
_sut = new {ClassName}();
}
[Test]
public void {MethodName}_When{Condition}_Should{Expectation}()
{
// Arrange
{setup_code}
// Act
var result = _sut.{MethodName}({parameters});
// Assert
Assert.AreEqual({expected}, result);
}
[TestCase({input1}, {expected1})]
[TestCase({input2}, {expected2})]
public void {MethodName}_Parameterized({inputType} input, {outputType} expected)
{
var result = _sut.{MethodName}(input);
Assert.AreEqual(expected, result);
}
}
```
### Unreal (C++)
**Knowledge Base Reference**: `knowledge/unreal-testing.md`
```cpp
#include "Misc/AutomationTest.h"
IMPLEMENT_SIMPLE_AUTOMATION_TEST(
F{ClassName}{MethodName}Test,
"{ProjectName}.{Category}.{TestName}",
EAutomationTestFlags::ApplicationContextMask |
EAutomationTestFlags::ProductFilter
)
bool F{ClassName}{MethodName}Test::RunTest(const FString& Parameters)
{
// Arrange
{setup_code}
// Act
auto Result = {ClassName}::{MethodName}({parameters});
// Assert
TestEqual("{assertion_message}", Result, {expected});
return true;
}
```
### Godot (GDScript)
**Knowledge Base Reference**: `knowledge/godot-testing.md`
```gdscript
extends GutTest
var _sut: {ClassName}
func before_each():
_sut = {ClassName}.new()
func after_each():
_sut.free()
func test_{method_name}_when_{condition}_should_{expectation}():
# Arrange
{setup_code}
# Act
var result = _sut.{method_name}({parameters})
# Assert
assert_eq(result, {expected}, "{assertion_message}")
func test_{method_name}_parameterized():
var test_cases = [
{{"input": {input1}, "expected": {expected1}}},
{{"input": {input2}, "expected": {expected2}}}
]
for tc in test_cases:
var result = _sut.{method_name}(tc.input)
assert_eq(result, tc.expected)
```
---
## Step 3: Generate Integration Tests
### Scene/Level Testing
**Unity Play Mode**:
```csharp
[UnityTest]
public IEnumerator {SceneName}_Loads_WithoutErrors()
{
SceneManager.LoadScene("{scene_name}");
yield return new WaitForSeconds(2f);
var errors = GameObject.FindObjectsOfType<ErrorHandler>()
.Where(e => e.HasErrors);
Assert.IsEmpty(errors, "Scene should load without errors");
}
```
**Unreal Functional Test**:
```cpp
void A{TestName}::StartTest()
{
Super::StartTest();
// Setup test scenario
{setup}
// Verify conditions
if ({condition})
{
FinishTest(EFunctionalTestResult::Succeeded, "{message}");
}
else
{
FinishTest(EFunctionalTestResult::Failed, "{failure_message}");
}
}
```
**Godot Integration**:
```gdscript
func test_{feature}_integration():
var scene = load("res://scenes/{scene}.tscn").instantiate()
add_child(scene)
# Wait for scene ready
await get_tree().process_frame
# Test interaction
{test_code}
# Cleanup
scene.queue_free()
```
---
## Step 4: Generate Smoke Tests
Create critical path tests that run on every build:
```
Smoke Test Criteria:
1. Game launches without crash
2. Main menu is navigable
3. New game starts successfully
4. Core gameplay loop executes
5. Save/load works
```
### Example Smoke Test
```csharp
// Unity
[UnityTest, Timeout(60000)]
public IEnumerator Smoke_NewGame_StartsSuccessfully()
{
// Load main menu
SceneManager.LoadScene("MainMenu");
yield return new WaitForSeconds(2f);
// Start new game
var newGameButton = GameObject.Find("NewGameButton");
newGameButton.GetComponent<Button>().onClick.Invoke();
yield return new WaitForSeconds(5f);
// Verify gameplay loaded
var player = GameObject.FindWithTag("Player");
Assert.IsNotNull(player, "Player should exist after new game");
}
```
---
## Step 5: Generate Test Report
After generating tests, create summary:
```markdown
## Automation Summary
**Engine**: {Unity | Unreal | Godot}
**Tests Generated**: {count}
### Test Distribution
| Type | Count | Coverage |
| ----------- | ----- | ------------- |
| Unit Tests | {n} | {systems} |
| Integration | {n} | {features} |
| Smoke Tests | {n} | Critical path |
### Files Created
- `tests/unit/{file1}.{ext}`
- `tests/unit/{file2}.{ext}`
- `tests/integration/{file3}.{ext}`
### Next Steps
1. Review generated tests
2. Fill in test-specific logic
3. Run tests to verify
4. Add to CI pipeline
```
---
## Test Patterns
### Common Patterns to Generate
1. **Calculator/Logic Tests** - Pure functions
2. **State Machine Tests** - State transitions
3. **Event Tests** - Signal/delegate firing
4. **Resource Tests** - ScriptableObject/Resource validation
5. **Serialization Tests** - Save/load round-trip
### Anti-Patterns to Avoid
- Testing engine functionality
- Hard-coded waits (use signals/events)
- Tests that depend on execution order
- Tests without cleanup
---
## Deliverables
1. **Unit Test Files** - Per-class test coverage
2. **Integration Test Files** - Feature-level tests
3. **Smoke Test Suite** - Critical path validation
4. **Automation Summary** - Coverage report
---
## Validation
Refer to `checklist.md` for validation criteria.
@@ -0,0 +1,48 @@
# Game QA workflow: automate
name: gametest-automate
description: "Generate automated game tests for Unity, Unreal, or Godot based on test design scenarios"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/gametest/automate"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Variables and inputs
variables:
test_dir: "{project-root}/tests"
source_dir: "{project-root}/src"
coverage_target: "critical-paths" # critical-paths, comprehensive, selective
game_engine: "auto" # auto, unity, unreal, godot
# Output configuration
default_output_file: "{output_folder}/automation-summary.md"
# Required tools
required_tools:
- read_file
- write_file
- create_directory
- list_files
- search_repo
- glob
tags:
- qa
- automation
- game-testing
- regression
- coverage
execution_hints:
interactive: false
autonomous: true
iterative: true
@@ -0,0 +1,96 @@
# Performance Testing - Validation Checklist
---
## Prerequisites
- [ ] Target platforms identified
- [ ] Hardware specs defined (min/recommended)
- [ ] Performance targets established
- [ ] Profiling tools available
---
## Target Definition
- [ ] Frame rate targets per platform
- [ ] Memory budgets per platform
- [ ] Loading time targets defined
- [ ] Regression thresholds set
---
## Test Scenarios
### Frame Rate Tests
- [ ] Stress test scenarios created
- [ ] Worst-case scenarios identified
- [ ] Benchmark levels available
- [ ] Automated tests possible
### Memory Tests
- [ ] Leak detection scenarios
- [ ] Extended play scenarios
- [ ] Level transition tests
- [ ] Maximum content scenarios
### Loading Tests
- [ ] Cold boot test defined
- [ ] Level load tests defined
- [ ] Save/load tests defined
- [ ] Fast travel tests (if applicable)
---
## Methodology
- [ ] Automated test framework identified
- [ ] Manual profiling checklist created
- [ ] Measurement tools specified
- [ ] Data collection process defined
---
## Benchmarks
- [ ] Benchmark scenarios defined
- [ ] Baseline metrics captured
- [ ] Regression criteria established
- [ ] CI integration planned
---
## Platform Coverage
- [ ] PC specs covered (min/recommended)
- [ ] Console modes tested (performance/quality)
- [ ] Mobile tiers addressed
- [ ] Platform-specific issues documented
---
## Documentation
- [ ] Performance test plan complete
- [ ] Targets documented
- [ ] Scenarios detailed
- [ ] Methodology explained
- [ ] Schedule defined
---
## Completion Criteria
- [ ] All platforms have performance targets
- [ ] Test scenarios cover critical areas
- [ ] Baseline metrics captured
- [ ] Automated tests in CI
---
**Completed by:** {name}
**Date:** {date}
**Platforms:** {list}
@@ -0,0 +1,323 @@
<!-- Powered by BMAD-CORE™ -->
# Performance Testing Strategy
**Workflow ID**: `_bmad/bmgd/gametest/performance`
**Version**: 1.0 (BMad v6)
---
## Overview
Design a comprehensive performance testing strategy covering frame rate, memory usage, loading times, and platform-specific requirements. Performance directly impacts player experience.
**Knowledge Base Reference**: `knowledge/performance-testing.md`
---
## Preflight Requirements
- ✅ Target platforms identified
- ✅ Performance requirements known (target FPS, memory limits)
- ✅ Representative content available for testing
- ✅ Profiling tools accessible
---
## Step 1: Define Performance Targets
### Frame Rate Targets
| Platform | Target FPS | Minimum FPS | Notes |
| ----------------- | ---------- | ----------- | ------------------ |
| PC (High) | 60+ | 30 | Uncapped option |
| PC (Low) | 30 | 30 | Scalable settings |
| PS5/Xbox X | 60 | 60 | Performance mode |
| PS4/Xbox One | 30 | 30 | Locked |
| Switch Docked | 30 | 30 | Stable |
| Switch Handheld | 30 | 25 | Power saving |
| Mobile (High) | 60 | 30 | Device dependent |
| Mobile (Standard) | 30 | 30 | Thermal throttling |
### Memory Budgets
| Platform | Total RAM | Game Budget | Notes |
| ------------- | --------- | ----------- | ------------------- |
| PC (Min spec) | 8 GB | 4 GB | Leave room for OS |
| PS5 | 16 GB | 12 GB | Unified memory |
| Xbox Series X | 16 GB | 13 GB | With Smart Delivery |
| Switch | 4 GB | 2.5 GB | Tight constraints |
| Mobile | 4-6 GB | 1.5-2 GB | Background apps |
### Loading Time Targets
| Scenario | Target | Maximum |
| ------------ | ------ | ------- |
| Initial boot | < 10s | 30s |
| Level load | < 15s | 30s |
| Fast travel | < 5s | 10s |
| Respawn | < 3s | 5s |
---
## Step 2: Identify Test Scenarios
### Stress Test Scenarios
Create scenarios that push performance limits:
```
SCENARIO: Maximum Entity Count
GIVEN game level with normal enemy spawn
WHEN enemy count reaches 50+
THEN frame rate stays above minimum
AND no visual artifacts
AND audio doesn't stutter
SCENARIO: Particle System Stress
GIVEN combat with multiple effects
WHEN 20+ particle systems active
THEN frame rate degradation < 20%
AND memory allocation stable
SCENARIO: Draw Call Stress
GIVEN level with maximum visible geometry
WHEN camera shows worst-case view
THEN frame rate stays above minimum
AND no hitching or stuttering
```
### Memory Test Scenarios
```
SCENARIO: Extended Play Session
GIVEN game running for 4+ hours
WHEN normal gameplay occurs
THEN memory usage remains stable
AND no memory leaks detected
AND no crash from fragmentation
SCENARIO: Level Transition
GIVEN player completes level
WHEN transitioning to new level
THEN previous level fully unloaded
AND memory baseline returns
AND no cumulative growth
```
### Loading Test Scenarios
```
SCENARIO: Cold Boot
GIVEN game not in memory
WHEN launching game
THEN reaches interactive state in < target
AND loading feedback shown
AND no apparent hang
SCENARIO: Save/Load Performance
GIVEN large save file (max progress)
WHEN loading save
THEN completes in < target
AND no corruption
AND gameplay resumes smoothly
```
---
## Step 3: Define Test Methodology
### Automated Performance Tests
**Unity Profiler Integration**:
```csharp
[UnityTest]
public IEnumerator Performance_CombatScene_MaintainsFPS()
{
using (Measure.ProfilerMarkers(new[] { "Main Thread" }))
{
SceneManager.LoadScene("CombatStressTest");
yield return new WaitForSeconds(30f);
}
var metrics = Measure.Custom(new SampleGroupDefinition("FPS"));
Assert.Greater(metrics.Median, 30, "FPS should stay above 30");
}
```
**Unreal Automation**:
```cpp
bool FPerformanceTest::RunTest(const FString& Parameters)
{
// Capture baseline
float StartTime = FPlatformTime::Seconds();
// Run stress scenario
for (int i = 0; i < 100; i++)
{
GetWorld()->SpawnActor<AStressTestActor>();
}
// Measure frame time
float FrameTime = FApp::GetDeltaTime();
TestTrue("Frame time under budget", FrameTime < 0.033f); // 30 FPS
return true;
}
```
**Godot Benchmark**:
```gdscript
func test_performance_entity_stress():
var frame_times = []
# Spawn stress load
for i in range(100):
var entity = stress_entity.instantiate()
add_child(entity)
# Collect frame times
for i in range(300): # 5 seconds at 60fps
await get_tree().process_frame
frame_times.append(Performance.get_monitor(Performance.TIME_PROCESS))
# Analyze
var avg_frame_time = frame_times.reduce(func(a, b): return a + b) / frame_times.size()
assert_lt(avg_frame_time, 0.033, "Average frame time under 33ms (30 FPS)")
```
### Manual Profiling Checklist
1. **CPU Profiling**
- [ ] Identify hotspots
- [ ] Check GC frequency
- [ ] Verify multithreading usage
2. **GPU Profiling**
- [ ] Draw call count
- [ ] Overdraw analysis
- [ ] Shader complexity
3. **Memory Profiling**
- [ ] Heap allocation patterns
- [ ] Asset memory usage
- [ ] Leak detection over time
---
## Step 4: Create Benchmark Suite
### Benchmark Levels
Create dedicated benchmark scenarios:
| Benchmark | Purpose | Duration |
| --------------- | ------------------------ | -------- |
| Combat Stress | Max entities, effects | 60s |
| Open World | Draw distance, streaming | 120s |
| Menu Navigation | UI performance | 30s |
| Save/Load | Persistence performance | 30s |
### Baseline Capture
1. Run benchmarks on reference hardware
2. Record baseline metrics
3. Set regression thresholds (e.g., 10% degradation = fail)
4. Integrate into CI pipeline
---
## Step 5: Platform-Specific Testing
### PC Testing
- Test across min/recommended specs
- Verify quality settings work
- Check VRAM usage at each tier
- Test at multiple resolutions
### Console Testing
- Test in both performance/quality modes
- Verify thermal throttling behavior
- Check suspend/resume impact
- Test with varying storage speeds
### Mobile Testing
- Test on low/mid/high tier devices
- Monitor thermal throttling
- Check battery impact
- Test with background apps
---
## Step 6: Generate Performance Test Plan
### Document Structure
```markdown
# Performance Test Plan: {Project Name}
## Performance Targets
[Tables for FPS, memory, loading times]
## Test Scenarios
### Frame Rate Tests
[Stress test scenarios]
### Memory Tests
[Extended play, leak detection scenarios]
### Loading Tests
[Boot, level load, save/load scenarios]
## Methodology
### Automated Tests
[Code examples, CI integration]
### Manual Profiling
[Checklist, tools to use]
## Benchmark Suite
[Benchmark definitions, baseline metrics]
## Platform Matrix
[Platform-specific requirements and tests]
## Regression Criteria
[What constitutes a performance regression]
## Schedule
[When performance tests run, who reviews]
```
---
## Deliverables
1. **Performance Test Plan** - Comprehensive strategy document
2. **Benchmark Scenarios** - Reproducible test levels
3. **Baseline Metrics** - Reference performance data
4. **Automated Tests** - CI-integrated performance tests
---
## Validation
Refer to `checklist.md` for validation criteria.
@@ -0,0 +1,256 @@
# Performance Test Plan: {PROJECT_NAME}
**Version**: {VERSION}
**Created**: {DATE}
**Author**: {AUTHOR}
---
## Overview
### Performance Philosophy
{High-level approach to performance for this project}
### Target Experience
- Primary target: {platform, e.g., "PS5 at 60 FPS"}
- Minimum viable: {platform, e.g., "PS4 at 30 FPS"}
---
## Performance Targets
### Frame Rate
| Platform | Target FPS | Minimum FPS | Mode |
| ------------- | ---------- | ----------- | ----------- |
| PC (High) | | | |
| PC (Low) | | | |
| PS5 | | | Performance |
| PS5 | | | Quality |
| Xbox Series X | | | |
| Switch | | | |
| Mobile | | | |
### Memory Budget
| Platform | Total RAM | Game Budget | Reserve |
| ------------- | --------- | ----------- | ------- |
| PC (Min) | | | |
| PS5 | | | |
| Xbox Series X | | | |
| Switch | | | |
| Mobile | | | |
### Loading Times
| Scenario | Target | Maximum | Notes |
| ------------ | ------ | ------- | ----- |
| Initial boot | | | |
| Level load | | | |
| Fast travel | | | |
| Respawn | | | |
| Save/Load | | | |
---
## Test Scenarios
### Frame Rate Stress Tests
#### Scenario: {Name}
```
GIVEN {setup conditions}
WHEN {stress conditions applied}
THEN frame rate >= {minimum}
AND frame time variance < {threshold}
PLATFORM: {target platforms}
```
{Repeat for each scenario}
### Memory Tests
#### Scenario: Extended Play Session
```
GIVEN game running for 4+ hours
WHEN normal gameplay patterns occur
THEN memory usage stays within budget
AND no detected memory leaks
AND GC pauses < 16ms
```
#### Scenario: Level Transition
```
GIVEN player completes level
WHEN loading next level
THEN previous level memory freed
AND memory returns to baseline (+/- 5%)
```
### Loading Time Tests
#### Scenario: Cold Boot
```
GIVEN game not in memory
WHEN launching from platform UI
THEN interactive menu in < {target}s
AND loading progress visible
```
---
## Benchmark Suite
### Benchmark Levels
| Name | Purpose | Duration | Key Metrics |
| ------------- | --------- | --------- | ------------------ |
| {Benchmark 1} | {purpose} | {seconds} | FPS, frame time |
| {Benchmark 2} | {purpose} | {seconds} | Draw calls, memory |
| {Benchmark 3} | {purpose} | {seconds} | Load time |
### Baseline Metrics
| Benchmark | Platform | FPS (Avg) | FPS (1%) | Memory | Date |
| --------- | -------- | --------- | -------- | ------ | ---- |
| | | | | | |
### Regression Criteria
| Metric | Warning | Failure |
| ----------- | ------- | ------- |
| FPS Average | -5% | -10% |
| FPS 1% Low | -10% | -20% |
| Memory | +5% | +10% |
| Load Time | +10% | +25% |
---
## Profiling Methodology
### Tools
| Platform | CPU Profiler | GPU Profiler | Memory |
| -------- | --------------- | ----------------- | --------------- |
| Unity | Unity Profiler | Frame Debugger | Memory Profiler |
| Unreal | Unreal Insights | RenderDoc | Memreport |
| Godot | Profiler | Shader debugger | Monitors |
| PC | PIX, vtune | RenderDoc, Nsight | RAMMap |
| PS5 | Razor | Razor GPU | - |
| Xbox | PIX | PIX | - |
### Profiling Checklist
#### CPU
- [ ] Main thread frame time
- [ ] Worker thread utilization
- [ ] GC frequency and duration
- [ ] Hotspot identification
#### GPU
- [ ] Draw call count
- [ ] Overdraw ratio
- [ ] Shader complexity
- [ ] Memory bandwidth
#### Memory
- [ ] Peak allocation
- [ ] Leak detection
- [ ] Fragmentation
- [ ] Asset memory breakdown
---
## Automated Tests
### CI Integration
```yaml
# Example CI configuration
performance-tests:
stage: test
script:
- ./run-benchmarks.sh
- ./check-regression.sh
artifacts:
reports:
performance: benchmark-results.json
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
```
### Automated Test Examples
{Engine-appropriate code examples}
---
## Platform-Specific Testing
### PC
- [ ] Test on minimum spec hardware
- [ ] Test on recommended spec hardware
- [ ] Verify quality presets work
- [ ] Check VRAM usage at each tier
- [ ] Test at 1080p, 1440p, 4K
### Console
- [ ] Test performance mode
- [ ] Test quality mode
- [ ] Check thermal throttling behavior
- [ ] Verify suspend/resume
- [ ] Test with HDD vs SSD (if applicable)
### Mobile
- [ ] Test on low-tier device
- [ ] Test on mid-tier device
- [ ] Test on high-tier device
- [ ] Monitor thermal throttling
- [ ] Check battery drain
---
## Schedule
| Activity | Frequency | Owner |
| ------------------ | --------- | --------- |
| Benchmark run | Daily | CI |
| Regression review | Weekly | QA Lead |
| Deep profiling | Milestone | Tech Lead |
| Platform soak test | Monthly | QA |
---
## Reporting
### Weekly Performance Report
- Benchmark trends
- Regression incidents
- Optimization progress
- Risk areas
### Release Criteria
- [ ] All platforms meet minimum FPS
- [ ] No memory leaks in 4-hour test
- [ ] Load times within targets
- [ ] No regression > failure threshold
---
## Notes
{Additional considerations, known issues, platform quirks}
@@ -0,0 +1,46 @@
# Game QA workflow: performance
name: gametest-performance
description: "Design performance testing strategy for frame rate, memory, and loading times"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/gametest/performance"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
template: "{installed_path}/performance-template.md"
# Variables and inputs
variables:
target_fps: 60
target_platform: "auto" # auto, pc, console, mobile
game_engine: "auto" # auto, unity, unreal, godot
# Output configuration
default_output_file: "{output_folder}/performance-test-plan.md"
# Required tools
required_tools:
- read_file
- write_file
- list_files
- search_repo
tags:
- qa
- performance
- profiling
- optimization
- benchmarks
execution_hints:
interactive: false
autonomous: true
iterative: true
@@ -0,0 +1,93 @@
# Playtest Planning - Validation Checklist
---
## Prerequisites
- [ ] Playable build available
- [ ] Build is stable (no crash blockers)
- [ ] Test objectives defined
- [ ] Participant criteria established
---
## Planning
- [ ] Playtest type selected (internal/external/focused)
- [ ] Session duration appropriate for objectives
- [ ] Participant count sufficient (5+ for patterns)
- [ ] Team roles assigned
---
## Session Structure
### Pre-Session
- [ ] Welcome script prepared
- [ ] Consent form ready (if recording)
- [ ] Setup instructions documented
- [ ] Accessibility accommodations considered
### Gameplay Session
- [ ] Focus areas identified
- [ ] Observation guide created
- [ ] Intervention rules defined
- [ ] Note-taking template ready
### Post-Session
- [ ] Interview questions prepared
- [ ] Questions are open-ended
- [ ] Time allocated for open feedback
---
## Observation Guide
- [ ] Key signals identified (confusion, frustration, engagement)
- [ ] Recording format defined
- [ ] Quantitative metrics listed
- [ ] All observers aligned on what to watch
---
## Documentation
- [ ] Playtest plan document complete
- [ ] Observation template attached
- [ ] Note-taking template included
- [ ] Report template prepared
---
## Logistics
- [ ] Build deployed and accessible
- [ ] Hardware ready and tested
- [ ] Recording equipment checked (if applicable)
- [ ] Quiet space secured
---
## Post-Playtest
- [ ] Debrief meeting scheduled
- [ ] Report deadline set
- [ ] Action item review planned
---
## Completion Criteria
- [ ] All team members have plan document
- [ ] Observers understand focus areas
- [ ] Templates are ready to use
- [ ] Build is stable for session
---
**Completed by:** {name}
**Date:** {date}
**Session Date:** {playtest_date}
@@ -0,0 +1,297 @@
<!-- Powered by BMAD-CORE™ -->
# Playtest Planning
**Workflow ID**: `_bmad/bmgd/gametest/playtest-plan`
**Version**: 1.0 (BMad v6)
---
## Overview
Create structured playtesting sessions to validate gameplay, gather user feedback, and identify issues that automated testing cannot catch. Playtesting validates "feel" and player experience.
**Knowledge Base Reference**: `knowledge/playtesting.md`
---
## Preflight Requirements
- ✅ Playable build available
- ✅ Test objectives defined
- ✅ Participant criteria known
---
## Step 1: Define Playtest Objectives
### Questions to Answer
1. **What are we testing?**
- Core gameplay loop
- Specific feature
- Difficulty curve
- Tutorial effectiveness
- Overall experience
2. **What decisions will this inform?**
- Design changes
- Difficulty tuning
- Feature prioritization
- Ship/no-ship decision
3. **What metrics will we collect?**
- Completion rates
- Time-on-task
- Failure points
- Player sentiment
---
## Step 2: Choose Playtest Type
### Internal Playtest
**Best for**: Early validation, bug finding, quick iterations
| Aspect | Details |
| ------------ | ------------------------- |
| Participants | Team members, other teams |
| Duration | 30-60 minutes |
| Frequency | Weekly or per-milestone |
| Setup | Minimal, informal |
### External Playtest
**Best for**: Unbiased feedback, market validation
| Aspect | Details |
| ------------ | --------------------------------- |
| Participants | Target audience, external testers |
| Duration | 1-2 hours |
| Frequency | Monthly or milestone |
| Setup | Formal, NDA if needed |
### Focused Playtest
**Best for**: Specific feature validation
| Aspect | Details |
| ------------ | ---------------------------- |
| Participants | Selected for specific traits |
| Duration | 20-45 minutes |
| Frequency | As needed |
| Setup | Specific build/scenario |
---
## Step 3: Create Session Structure
### Pre-Session (10-15 min)
1. **Welcome & Context**
- Brief game description (no spoilers)
- Session goals (what we're testing)
- Comfort check (breaks, questions)
2. **Consent & Setup**
- Recording consent (if applicable)
- Controller/input preferences
- Any accessibility needs
3. **Instructions**
- "Play as you normally would"
- "Think aloud if comfortable"
- "There are no wrong answers"
### Gameplay Session (30-90 min)
1. **Observation Focus Areas**
- Where do players get stuck?
- What do they try first?
- What surprises them?
- Where do they express frustration/joy?
2. **Note-Taking Template**
```
[TIME] [LOCATION] [OBSERVATION] [PLAYER REACTION]
0:05 Tutorial Skipped help text Seemed impatient
0:12 Combat Died to first enemy Frustrated, retried
```
3. **Intervention Rules**
- Let players struggle (within reason)
- Note when you want to help
- Only intervene for:
- Critical bugs
- Genuine distress
- Session time running out
### Post-Session (10-20 min)
1. **Immediate Reactions**
- "What was your overall impression?"
- "What stood out most?"
- "Would you play again?"
2. **Specific Questions**
- Feature-specific feedback
- Difficulty perception
- Clarity of objectives
3. **Open Feedback**
- "Anything else?"
- "Questions for us?"
---
## Step 4: Create Observation Guide
### What to Watch For
| Category | Signals | Record |
| ----------- | ------------------------------------- | ------------------ |
| Confusion | Pausing, wandering, repeating actions | Location, duration |
| Frustration | Sighing, repeated failures, quitting | Cause, frequency |
| Engagement | Leaning in, exclaiming, continuing | Features that work |
| Boredom | Checking phone, disengaging | Drop-off points |
### Quantitative Metrics
- Time to complete tutorial
- Deaths per section
- Items/features discovered
- Session duration
- Completion rate
---
## Step 5: Generate Playtest Plan Document
### Document Structure
```markdown
# Playtest Plan: {Build/Feature Name}
## Overview
- Build version: {version}
- Session date(s): {dates}
- Objective: {primary goal}
## Participant Criteria
- Target: {player type}
- Experience: {gaming background}
- Count: {number}
## Session Structure
### Pre-Session (15 min)
- Welcome and consent
- Setup and preferences
- Brief instructions
### Gameplay (60 min)
- Free play / guided tasks
- Observation focus: {areas}
- Intervention threshold: {criteria}
### Post-Session (15 min)
- Immediate reactions
- Structured questions
- Open feedback
## Observation Guide
{observation_template}
## Data Collection
- Recording: {yes/no}
- Notes template: {attached}
- Metrics: {list}
## Team Roles
- Facilitator: {name}
- Note-taker: {name}
- Technical support: {name}
## Post-Playtest Analysis
- Session debrief: {date}
- Report due: {date}
- Action items review: {date}
```
---
## Step 6: Post-Playtest Analysis
### Synthesize Findings
1. **Pattern Identification**
- What issues appeared multiple times?
- What worked consistently well?
2. **Severity Assessment**
- Critical: Blocks progression
- Major: Significantly impacts experience
- Minor: Noticeable but manageable
3. **Recommendations**
- Immediate fixes
- Design considerations
- Further investigation needed
### Report Template
```markdown
## Playtest Report: {Session}
### Summary
- Participants: {count}
- Completion rate: {%}
- Overall sentiment: {positive/mixed/negative}
### Key Findings
1. {Finding with evidence}
2. {Finding with evidence}
### Recommendations
| Issue | Severity | Recommendation | Priority |
| ------- | -------- | -------------- | -------- |
| {issue} | {sev} | {rec} | {P0-P3} |
### Quotes
> "{Notable player quote}" - Participant {N}
### Next Steps
1. {action item}
2. {action item}
```
---
## Deliverables
1. **Playtest Plan Document** - Session structure and logistics
2. **Observation Guide** - What to watch for
3. **Note-Taking Template** - Standardized recording
4. **Report Template** - Post-session analysis format
---
## Validation
Refer to `checklist.md` for validation criteria.
@@ -0,0 +1,208 @@
# Playtest Plan: {BUILD_NAME}
**Version**: {BUILD_VERSION}
**Created**: {DATE}
**Session Date(s)**: {PLAYTEST_DATES}
---
## Overview
### Objective
{What are we trying to learn from this playtest?}
### Build Information
- **Version**: {version}
- **Platform**: {PC/Console/Mobile}
- **Content**: {What's included in this build}
- **Known Issues**: {List any known bugs to ignore}
### Success Criteria
{How will we know the playtest was successful?}
---
## Participants
### Target Profile
- **Player Type**: {casual/core/hardcore}
- **Genre Experience**: {familiar/unfamiliar with genre}
- **Age Range**: {if relevant}
- **Other Criteria**: {specific requirements}
### Recruitment
- **Count**: {number of participants}
- **Source**: {internal/external/panel}
- **Compensation**: {if applicable}
---
## Session Structure
### Pre-Session (15 minutes)
1. **Welcome (5 min)**
- Introduce yourself and the team
- Explain what they'll be doing
- Emphasize: "We're testing the game, not you"
2. **Consent & Setup (5 min)**
- Recording consent: {yes/no}
- NDA: {yes/no}
- Collect demographic info: {yes/no}
- Hardware preferences
3. **Instructions (5 min)**
- "Play as you normally would"
- "Think out loud if you're comfortable"
- "Ask questions anytime"
- "You can stop at any time"
### Gameplay Session ({DURATION} minutes)
#### Free Play vs Guided Tasks
- [ ] Free play - Let player explore naturally
- [ ] Guided tasks - Specific scenarios to complete
#### Focus Areas
1. {Area 1 - e.g., Tutorial effectiveness}
2. {Area 2 - e.g., Combat feel}
3. {Area 3 - e.g., Navigation clarity}
#### Intervention Threshold
Only intervene when:
- [ ] Critical bug prevents progress
- [ ] Player is genuinely distressed
- [ ] Session time is running out
- [ ] Player explicitly asks for help
### Post-Session ({POST_DURATION} minutes)
#### Immediate Reactions
1. "What was your overall impression of the game?"
2. "What moment stood out the most?"
3. "Would you play this again? Why or why not?"
#### Feature-Specific Questions
1. {Question about focus area 1}
2. {Question about focus area 2}
3. {Question about focus area 3}
#### Open Feedback
1. "Is there anything you wish the game had?"
2. "Anything else you'd like to share?"
3. "Questions for us?"
---
## Observation Guide
### What to Watch For
| Signal | Examples | Action |
| --------------- | -------------------------------------- | ------------------------- |
| **Confusion** | Pausing, circling, re-reading | Note location, duration |
| **Frustration** | Sighing, repeated attempts, quitting | Note cause, frequency |
| **Engagement** | Leaning in, exclaiming, "one more try" | Note feature |
| **Boredom** | Checking phone, rushing, disengaging | Note when drop-off begins |
| **Discovery** | "Oh!", trying things | Note what triggered it |
### Metrics to Collect
- [ ] Time to complete tutorial
- [ ] Number of deaths/failures per section
- [ ] Features/items discovered
- [ ] Total session duration
- [ ] Completion rate
---
## Note-Taking Template
```
Participant: ___ Date: ___ Observer: ___
TIME | LOCATION | OBSERVATION | REACTION | NOTES
-----|----------|-------------|----------|------
| | | |
| | | |
| | | |
Key Moments:
1.
2.
3.
Overall Impression:
```
---
## Team Roles
| Role | Responsibilities | Assigned To |
| ---------------- | --------------------------------- | ----------- |
| **Facilitator** | Welcome, instructions, interview | {name} |
| **Note-taker** | Observations, timestamps | {name} |
| **Tech Support** | Build, recording, troubleshooting | {name} |
---
## Logistics
### Equipment
- [ ] Game build installed and tested
- [ ] Controllers/input devices
- [ ] Recording equipment (if applicable)
- [ ] Consent forms
- [ ] Observation templates (printed)
- [ ] Compensation (if applicable)
### Environment
- [ ] Quiet, private space
- [ ] Comfortable seating
- [ ] Water/snacks available
- [ ] Clock/timer visible
---
## Post-Playtest Process
### Same Day
- [ ] Quick team debrief (15 min)
- [ ] Consolidate raw notes
- [ ] Flag critical issues
### Within 48 Hours
- [ ] Synthesize findings
- [ ] Identify patterns
- [ ] Draft playtest report
### Report Delivery
- **Due Date**: {date}
- **Distribution**: {team/stakeholders}
- **Format**: {document/presentation}
---
## Notes
{Any additional notes, special considerations, or reminders}
@@ -0,0 +1,57 @@
# Game QA workflow: playtest-plan
name: gametest-playtest-plan
description: "Create structured playtesting sessions for gameplay validation and user feedback"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/gametest/playtest-plan"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
template: "{installed_path}/playtest-template.md"
# Variables and inputs
variables:
playtest_type: "internal" # internal, external, focused
session_duration: 60 # minutes
participant_count: 5
# Smart input file references - for understanding game mechanics to test
input_file_patterns:
gdd:
description: "Game Design Document for mechanics to validate"
whole: "{output_folder}/*gdd*.md"
sharded: "{output_folder}/*gdd*/*.md"
load_strategy: "FULL_LOAD"
game_brief:
description: "Game Brief for understanding core pillars"
whole: "{output_folder}/*brief*.md"
load_strategy: "FULL_LOAD"
# Output configuration
default_output_file: "{output_folder}/playtest-plan.md"
# Required tools
required_tools:
- read_file
- write_file
- list_files
tags:
- qa
- playtesting
- user-research
- design-validation
- feedback
execution_hints:
interactive: true
autonomous: false
iterative: true
@@ -0,0 +1,98 @@
# Game Test Design - Validation Checklist
---
## Prerequisites
- [ ] Game design documentation reviewed
- [ ] Core mechanics identified
- [ ] Target platforms known
- [ ] Risk areas assessed
---
## Context Gathering
- [ ] GDD or feature specs located
- [ ] Core gameplay loop understood
- [ ] Progression systems identified
- [ ] Multiplayer requirements known (if applicable)
- [ ] Platform certification needs identified
---
## Test Categories
### Gameplay Tests
- [ ] Core loop scenarios created
- [ ] Combat/interaction tests defined
- [ ] Movement/physics tests defined
- [ ] UI/UX tests defined
### Progression Tests
- [ ] Save/load scenarios created
- [ ] Unlock system tests defined
- [ ] Economy tests defined
- [ ] Achievement tests defined
### Multiplayer Tests (if applicable)
- [ ] Connectivity scenarios created
- [ ] Sync validation tests defined
- [ ] Latency tests defined
- [ ] Matchmaking tests defined
### Platform Tests
- [ ] Certification requirements covered
- [ ] Input handling tests defined
- [ ] Performance criteria established
- [ ] Accessibility tests defined
---
## Scenario Quality
- [ ] All scenarios use GIVEN/WHEN/THEN format
- [ ] Scenarios have clear expected outcomes
- [ ] Priorities assigned (P0-P3)
- [ ] Categories assigned
- [ ] No duplicate scenarios
- [ ] Edge cases considered
---
## Prioritization
- [ ] P0 scenarios cover ship blockers
- [ ] P1 scenarios cover major features
- [ ] Priority distribution is reasonable
- [ ] Risk-based ordering applied
---
## Documentation
- [ ] Test design document created
- [ ] Overview section complete
- [ ] Risk assessment included
- [ ] Coverage matrix generated
- [ ] Automation recommendations provided
- [ ] Next steps defined
---
## Completion Criteria
- [ ] All critical systems have test coverage
- [ ] Scenarios are actionable and testable
- [ ] Document is ready for team review
- [ ] Automation candidates identified
---
**Completed by:** {name}
**Date:** {date}
**Scenario Count:** {count}
@@ -0,0 +1,280 @@
<!-- Powered by BMAD-CORE™ -->
# Game Test Design
**Workflow ID**: `_bmad/bmgd/gametest/test-design`
**Version**: 1.0 (BMad v6)
---
## Overview
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.
---
## Preflight Requirements
- ✅ Game design documentation available (GDD, feature specs)
- ✅ Understanding of target platforms
- ✅ Knowledge of core gameplay loop
---
## Step 1: Gather Context
### Actions
1. **Read Game Design Documentation**
- Locate GDD or game-design.md
- Identify core mechanics and features
- Note target platforms and certification requirements
2. **Identify Critical Systems**
- Core gameplay loop
- Progression/save systems
- Multiplayer (if applicable)
- Monetization (if applicable)
3. **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 |
---
## 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
```
---
## Step 4: Prioritize Test Coverage
### Priority Assignment
**Knowledge Base Reference**: `knowledge/test-priorities.md`
| Priority | Criteria | Coverage Target |
| -------- | ---------------------------- | --------------- |
| P0 | Ship blockers, certification | 100% automated |
| P1 | Major features, common paths | 80% automated |
| P2 | Secondary features | 60% automated |
| P3 | Edge cases, polish | Manual only |
### Risk-Based Ordering
1. **Critical Path** - Main gameplay loop
2. **Data Integrity** - Save/load, progression
3. **Platform Requirements** - Certification items
4. **User Experience** - Feel, polish, accessibility
---
## Step 5: Generate Test Design Document
### Document Structure
```markdown
# 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
1. **Test Design Document** - `{output_folder}/game-test-design.md`
2. **Scenario List** - Prioritized test scenarios
3. **Coverage Matrix** - Feature vs priority breakdown
4. **Automation Recommendations** - What to automate vs manual test
---
## Output Summary
```markdown
## 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
**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.
@@ -0,0 +1,205 @@
# Game Test Design: {PROJECT_NAME}
**Version**: 1.0
**Created**: {DATE}
**Author**: {AUTHOR}
---
## Overview
### Game Description
{Brief description of the game, genre, and core mechanics}
### Target Platforms
- [ ] PC (Steam/Epic)
- [ ] PlayStation 5
- [ ] Xbox Series X|S
- [ ] Nintendo Switch
- [ ] Mobile (iOS/Android)
### Test Scope
{What is in scope and out of scope for testing}
---
## Risk Assessment
### High-Risk Areas
| Area | Risk | Mitigation |
| ------ | ----------------- | --------------- |
| {area} | {potential issue} | {test strategy} |
### Risk Priority Matrix
```
IMPACT
Low High
┌─────────┬─────────┐
High │ P2 │ P0 │
LIKELIHOOD ├─────────┼─────────┤
Low │ P3 │ P1 │
└─────────┴─────────┘
```
---
## Test Categories
### 1. Core Gameplay Tests
#### 1.1 Core Loop
```
SCENARIO: {Scenario Name}
GIVEN {preconditions}
WHEN {action}
THEN {expected outcome}
PRIORITY: P0
CATEGORY: gameplay
```
#### 1.2 Combat/Interaction
{scenarios}
#### 1.3 Movement/Physics
{scenarios}
---
### 2. Progression Tests
#### 2.1 Save/Load System
```
SCENARIO: Basic Save/Load Round Trip
GIVEN player has made progress
WHEN game is saved and reloaded
THEN all progress is preserved
PRIORITY: P0
CATEGORY: progression
```
#### 2.2 Unlock System
{scenarios}
#### 2.3 Economy
{scenarios}
---
### 3. Multiplayer Tests (if applicable)
#### 3.1 Connectivity
{scenarios}
#### 3.2 Synchronization
{scenarios}
#### 3.3 Network Degradation
{scenarios}
---
### 4. Platform Tests
#### 4.1 Certification Requirements
{scenarios for TRC/XR items}
#### 4.2 Input Handling
{scenarios}
#### 4.3 Performance
{scenarios}
#### 4.4 Accessibility
{scenarios}
---
## Coverage Matrix
| Feature | P0 | P1 | P2 | P3 | Total |
| ------------- | --- | --- | --- | --- | ----- |
| Core Gameplay | | | | | |
| Combat | | | | | |
| Progression | | | | | |
| Save/Load | | | | | |
| Multiplayer | | | | | |
| Platform | | | | | |
| **Total** | | | | | |
---
## Automation Strategy
### Recommended for Automation (Unit/Integration)
- {feature/scenario} - Reason
- {feature/scenario} - Reason
### Manual Testing Required
- {feature/scenario} - Reason (e.g., requires human judgment on "feel")
- {feature/scenario} - Reason
### Automation Tools
- **Engine**: {Unity/Unreal/Godot}
- **Framework**: {Unity Test Framework/Unreal Automation/GUT}
- **CI Integration**: {GitHub Actions/Jenkins/etc.}
---
## Playtesting Recommendations
### Internal Playtests
- Focus: Core loop validation
- Participants: QA + dev team
- Duration: {hours}
### External Playtests
- Focus: User experience, difficulty curve
- Participants: Target audience
- Duration: {hours}
---
## Next Steps
1. [ ] Review test design with team
2. [ ] Prioritize P0 test implementation
3. [ ] Set up test framework (use `framework` workflow)
4. [ ] Generate automated tests (use `automate` workflow)
5. [ ] Plan playtesting sessions (use `playtest-plan` workflow)
---
## Appendix
### Glossary
{Game-specific terms and definitions}
### References
- Game Design Document
- Platform Certification Guidelines
- Knowledge Base: `qa-index.csv`
@@ -0,0 +1,45 @@
# Game QA workflow: test-design
name: gametest-test-design
description: "Create comprehensive game test scenarios covering gameplay, progression, and quality requirements"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/gametest/test-design"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
template: "{installed_path}/test-design-template.md"
# Variables and inputs
variables:
design_level: "full" # full, targeted, minimal
focus_area: "auto" # auto, gameplay, progression, multiplayer, performance
# Output configuration
default_output_file: "{output_folder}/game-test-design.md"
# Required tools
required_tools:
- read_file
- write_file
- list_files
- search_repo
tags:
- qa
- planning
- game-testing
- risk-assessment
- coverage
execution_hints:
interactive: false
autonomous: true
iterative: true
@@ -0,0 +1,103 @@
# Game Test Framework Setup - Validation Checklist
This checklist ensures the framework workflow completes successfully.
---
## Prerequisites
- [ ] Game project exists with identifiable engine
- [ ] Engine type detected (Unity, Unreal, or Godot)
- [ ] No existing test framework conflicts
- [ ] Write permissions to create directories
---
## Engine Detection
- [ ] Engine type correctly identified
- [ ] Engine version detected
- [ ] Project structure understood
---
## Unity-Specific Checks
- [ ] `Assets/Tests/` directory created
- [ ] `EditMode/` subdirectory created with `.asmdef`
- [ ] `PlayMode/` subdirectory created with `.asmdef`
- [ ] Assembly definitions reference game assembly
- [ ] `UNITY_INCLUDE_TESTS` constraint set
- [ ] Sample Edit Mode test created
- [ ] Sample Play Mode test created
- [ ] Tests compile without errors
---
## Unreal-Specific Checks
- [ ] `Source/<ProjectName>Tests/` directory created
- [ ] `<ProjectName>Tests.Build.cs` created
- [ ] Module references game module correctly
- [ ] Sample automation test created
- [ ] Test flags set correctly (`ProductFilter`)
- [ ] Tests compile without errors
---
## Godot-Specific Checks
- [ ] GUT plugin installed in `addons/gut/`
- [ ] `tests/` directory created
- [ ] `tests/unit/` subdirectory created
- [ ] `tests/integration/` subdirectory created
- [ ] `gut_config.json` created
- [ ] Sample test extends `GutTest`
- [ ] `before_each`/`after_each` patterns used
- [ ] Tests run without errors
---
## Sample Tests
- [ ] Sample tests follow engine conventions
- [ ] Tests use Arrange-Act-Assert pattern
- [ ] Tests include proper cleanup
- [ ] Tests demonstrate framework capabilities
- [ ] Tests are syntactically correct
---
## Documentation
- [ ] `tests/README.md` created
- [ ] Setup instructions included
- [ ] Running tests section included
- [ ] CI integration commands included
- [ ] Best practices section included
---
## Quality Checks
- [ ] No compilation/syntax errors
- [ ] No placeholder text left
- [ ] No hardcoded paths (use engine conventions)
- [ ] Cleanup prevents orphan objects
- [ ] Tests are deterministic
---
## Completion Criteria
- [ ] Engine correctly detected
- [ ] Directory structure created
- [ ] Configuration files generated
- [ ] Sample tests run successfully
- [ ] Documentation complete
---
**Completed by:** {name}
**Date:** {date}
**Engine:** {Unity | Unreal | Godot}
@@ -0,0 +1,348 @@
<!-- Powered by BMAD-CORE™ -->
# Game Test Framework Setup
**Workflow ID**: `_bmad/bmgd/gametest/framework`
**Version**: 1.0 (BMad v6)
---
## Overview
Initialize a production-ready game test framework for Unity, Unreal Engine, or Godot projects. This workflow scaffolds the complete testing infrastructure including unit tests, integration tests, and play mode tests appropriate for the detected game engine.
---
## Preflight Requirements
**Critical:** Verify these requirements before proceeding. If any fail, HALT and notify the user.
- ✅ Game project exists with identifiable engine
- ✅ No test framework already configured (check for existing test directories)
- ✅ Project structure is accessible
---
## Step 1: Detect Game Engine
### Actions
1. **Identify Engine Type**
Look for engine-specific files:
- **Unity**: `Assets/`, `ProjectSettings/ProjectSettings.asset`, `*.unity` scene files
- **Unreal**: `*.uproject`, `Source/`, `Config/DefaultEngine.ini`
- **Godot**: `project.godot`, `*.tscn`, `*.gd` files
2. **Verify Engine Version**
- Unity: Check `ProjectSettings/ProjectVersion.txt`
- Unreal: Check `*.uproject` file for `EngineAssociation`
- Godot: Check `project.godot` for `config_version`
3. **Check for Existing Test Framework**
- Unity: Check for `Tests/` folder, `*.Tests.asmdef`
- Unreal: Check for `Tests/` in Source, `*Tests.Build.cs`
- Godot: Check for `tests/` folder, GUT plugin in `addons/gut/`
**Halt Condition:** If existing framework detected, offer upgrade path or HALT.
---
## Step 2: Scaffold Framework
### Unity Test Framework
**Knowledge Base Reference**: `knowledge/unity-testing.md`
1. **Create Directory Structure**
```
Assets/
├── Tests/
│ ├── EditMode/
│ │ ├── EditModeTests.asmdef
│ │ └── ExampleEditModeTest.cs
│ └── PlayMode/
│ ├── PlayModeTests.asmdef
│ └── ExamplePlayModeTest.cs
```
2. **Generate Assembly Definitions**
`EditModeTests.asmdef`:
```json
{
"name": "EditModeTests",
"references": ["<GameAssembly>"],
"includePlatforms": ["Editor"],
"defineConstraints": ["UNITY_INCLUDE_TESTS"],
"optionalUnityReferences": ["TestAssemblies"]
}
```
`PlayModeTests.asmdef`:
```json
{
"name": "PlayModeTests",
"references": ["<GameAssembly>"],
"includePlatforms": [],
"defineConstraints": ["UNITY_INCLUDE_TESTS"],
"optionalUnityReferences": ["TestAssemblies"]
}
```
3. **Generate Sample Tests**
Edit Mode test example:
```csharp
using NUnit.Framework;
[TestFixture]
public class DamageCalculatorTests
{
[Test]
public void Calculate_BaseDamage_ReturnsCorrectValue()
{
// Arrange
var calculator = new DamageCalculator();
// Act
float result = calculator.Calculate(100f, 1f);
// Assert
Assert.AreEqual(100f, result);
}
}
```
Play Mode test example:
```csharp
using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.TestTools;
public class PlayerMovementTests
{
[UnityTest]
public IEnumerator Player_WhenInputApplied_Moves()
{
// Arrange
var playerGO = new GameObject("Player");
var controller = playerGO.AddComponent<PlayerController>();
// Act
controller.SetMoveInput(Vector2.right);
yield return new WaitForSeconds(0.5f);
// Assert
Assert.Greater(playerGO.transform.position.x, 0f);
// Cleanup
Object.Destroy(playerGO);
}
}
```
---
### Unreal Engine Automation
**Knowledge Base Reference**: `knowledge/unreal-testing.md`
1. **Create Directory Structure**
```
Source/
├── <ProjectName>/
│ └── ...
└── <ProjectName>Tests/
├── <ProjectName>Tests.Build.cs
└── Private/
├── DamageCalculationTests.cpp
└── PlayerCombatTests.cpp
```
2. **Generate Module Build File**
`<ProjectName>Tests.Build.cs`:
```csharp
using UnrealBuildTool;
public class <ProjectName>Tests : ModuleRules
{
public <ProjectName>Tests(ReadOnlyTargetRules Target) : base(Target)
{
PCHUsage = ModuleRules.PCHUsageMode.UseExplicitOrSharedPCHs;
PublicDependencyModuleNames.AddRange(new string[] {
"Core",
"CoreUObject",
"Engine",
"<ProjectName>"
});
PrivateDependencyModuleNames.AddRange(new string[] {
"AutomationController"
});
}
}
```
3. **Generate Sample Tests**
```cpp
#include "Misc/AutomationTest.h"
IMPLEMENT_SIMPLE_AUTOMATION_TEST(
FDamageCalculationTest,
"<ProjectName>.Combat.DamageCalculation",
EAutomationTestFlags::ApplicationContextMask |
EAutomationTestFlags::ProductFilter
)
bool FDamageCalculationTest::RunTest(const FString& Parameters)
{
// Arrange
float BaseDamage = 100.f;
float CritMultiplier = 2.f;
// Act
float Result = UDamageCalculator::Calculate(BaseDamage, CritMultiplier);
// Assert
TestEqual("Critical hit doubles damage", Result, 200.f);
return true;
}
```
---
### Godot GUT Framework
**Knowledge Base Reference**: `knowledge/godot-testing.md`
1. **Create Directory Structure**
```
project/
├── addons/
│ └── gut/ (plugin files)
├── tests/
│ ├── unit/
│ │ └── test_damage_calculator.gd
│ └── integration/
│ └── test_player_combat.gd
└── gut_config.json
```
2. **Generate GUT Configuration**
`gut_config.json`:
```json
{
"dirs": ["res://tests/"],
"include_subdirs": true,
"prefix": "test_",
"suffix": ".gd",
"should_exit": true,
"should_exit_on_success": true,
"log_level": 1,
"junit_xml_file": "results.xml"
}
```
3. **Generate Sample Tests**
`tests/unit/test_damage_calculator.gd`:
```gdscript
extends GutTest
var calculator: DamageCalculator
func before_each():
calculator = DamageCalculator.new()
func after_each():
calculator.free()
func test_calculate_base_damage():
var result = calculator.calculate(100.0, 1.0)
assert_eq(result, 100.0, "Base damage should equal input")
func test_calculate_critical_hit():
var result = calculator.calculate(100.0, 2.0)
assert_eq(result, 200.0, "Critical hit should double damage")
```
---
## Step 3: Generate Documentation
Create `tests/README.md` with:
- Test framework overview for the detected engine
- Directory structure explanation
- Running tests locally
- CI integration commands
- Best practices for game testing
- Links to knowledge base fragments
---
## Step 4: Deliverables
### Primary Artifacts Created
1. **Directory Structure** - Engine-appropriate test folders
2. **Configuration Files** - Framework-specific config (asmdef, Build.cs, gut_config.json)
3. **Sample Tests** - Working examples for unit and integration tests
4. **Documentation** - `tests/README.md`
---
## Output Summary
After completing this workflow, provide a summary:
```markdown
## Game Test Framework Scaffold Complete
**Engine Detected**: {Unity | Unreal | Godot}
**Framework**: {Unity Test Framework | Unreal Automation | GUT}
**Artifacts Created**:
- ✅ Test directory structure
- ✅ Framework configuration
- ✅ Sample unit tests
- ✅ Sample integration/play mode tests
- ✅ Documentation
**Next Steps**:
1. Review sample tests and adapt to your game
2. Run initial tests to verify setup
3. Use `test-design` workflow to plan comprehensive test coverage
4. Use `automate` workflow to generate additional tests
**Knowledge Base References Applied**:
- {engine}-testing.md
- qa-automation.md
- test-priorities.md
```
---
## Validation
Refer to `checklist.md` for comprehensive validation criteria.
@@ -0,0 +1,46 @@
# Game QA workflow: framework
name: gametest-framework
description: "Initialize game test framework architecture for Unity, Unreal Engine, or Godot projects"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/gametest/test-framework"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Variables and inputs
variables:
test_dir: "{project-root}/tests" # Root test directory
game_engine: "auto" # auto, unity, unreal, godot
test_framework: "auto" # auto, gut (godot), unity-test-framework, unreal-automation
# Output configuration
default_output_file: "{test_dir}/README.md"
# Required tools
required_tools:
- read_file
- write_file
- create_directory
- list_files
- search_repo
tags:
- qa
- setup
- game-testing
- framework
- initialization
execution_hints:
interactive: false
autonomous: true
iterative: true
@@ -0,0 +1,87 @@
# Test Review - Validation Checklist
---
## Prerequisites
- [ ] Test suite accessible
- [ ] Test results available
- [ ] Feature list known
- [ ] Access to CI/CD pipeline
---
## Metrics Collection
- [ ] Test counts by type gathered
- [ ] Pass rates calculated
- [ ] Average durations measured
- [ ] Flaky tests identified
- [ ] Slow tests identified
- [ ] Disabled tests listed
---
## Quality Assessment
- [ ] Determinism evaluated
- [ ] Isolation checked
- [ ] Speed benchmarked
- [ ] Readability assessed
- [ ] Anti-patterns documented
---
## Coverage Analysis
- [ ] All features listed
- [ ] Test coverage mapped
- [ ] P0/P1 coverage verified
- [ ] Critical gaps identified
- [ ] Gap priorities assigned
---
## Infrastructure Review
- [ ] CI integration verified
- [ ] Results visibility confirmed
- [ ] Failure blocking assessed
- [ ] Fixture quality evaluated
- [ ] Maintenance burden estimated
---
## Recommendations
- [ ] Findings prioritized
- [ ] Effort estimated
- [ ] Immediate actions identified
- [ ] Short-term improvements listed
- [ ] Long-term strategy outlined
---
## Report
- [ ] Executive summary complete
- [ ] Metrics section complete
- [ ] Quality assessment documented
- [ ] Coverage analysis included
- [ ] Recommendations actionable
- [ ] Appendices populated
---
## Completion Criteria
- [ ] All test types reviewed
- [ ] Critical gaps identified
- [ ] Actionable recommendations provided
- [ ] Report delivered to stakeholders
---
**Completed by:** {name}
**Date:** {date}
**Tests Reviewed:** {count}
@@ -0,0 +1,272 @@
<!-- Powered by BMAD-CORE™ -->
# Test Review
**Workflow ID**: `_bmad/bmgd/gametest/test-review`
**Version**: 1.0 (BMad v6)
---
## Overview
Review existing test suite quality, identify coverage gaps, and recommend improvements. Regular test review prevents test rot and maintains test value over time.
**Knowledge Base Reference**: `knowledge/regression-testing.md`, `knowledge/test-priorities.md`
---
## Preflight Requirements
- ✅ Test suite exists (some tests to review)
- ✅ Access to test execution results
- ✅ Understanding of game features
---
## Step 1: Gather Test Suite Metrics
### Actions
1. **Count Tests by Type**
| Type | Count | Pass Rate | Avg Duration |
| -------------------- | ----- | --------- | ------------ |
| Unit | | | |
| Integration | | | |
| Play Mode/Functional | | | |
| Performance | | | |
| **Total** | | | |
2. **Analyze Test Results**
- Recent pass rate (last 10 runs)
- Flaky tests (inconsistent results)
- Slow tests (> 30s individual)
- Disabled/skipped tests
3. **Map Coverage**
- Features with tests
- Features without tests
- Critical paths covered
---
## Step 2: Assess Test Quality
### Quality Criteria
For each test, evaluate:
| Criterion | Good | Bad |
| ----------------- | -------------------------------- | ---------------------------- |
| **Deterministic** | Same input = same result | Flaky, timing-dependent |
| **Isolated** | No shared state | Tests affect each other |
| **Fast** | < 5s (unit), < 30s (integration) | Minutes per test |
| **Readable** | Clear intent, good names | Cryptic, no comments |
| **Maintained** | Up-to-date, passing | Disabled, stale |
| **Valuable** | Tests real behavior | Tests implementation details |
### Anti-Pattern Detection
Look for these common issues:
```
❌ Hard-coded waits
await Task.Delay(5000); // Bad
await WaitUntil(() => condition); // Good
❌ Shared test state
static bool wasSetup; // Dangerous
[SetUp] void Setup() { /* fresh state */ } // Good
❌ Testing private implementation
var result = obj.GetPrivateField(); // Bad
var result = obj.PublicBehavior(); // Good
❌ Missing cleanup
var go = Instantiate(prefab); // Leaks
var go = Instantiate(prefab);
AddCleanup(() => Destroy(go)); // Good
❌ Assertion-free tests
void Test() { DoSomething(); } // What does it test?
void Test() { DoSomething(); Assert.That(...); } // Clear
```
---
## Step 3: Identify Coverage Gaps
### Critical Areas to Verify
| Area | P0 Coverage | P1 Coverage | Gap? |
| ------------- | ----------- | ----------- | ---- |
| Core Loop | | | |
| Save/Load | | | |
| Progression | | | |
| Combat | | | |
| UI/Menus | | | |
| Multiplayer | | | |
| Platform Cert | | | |
### Gap Identification Process
1. List all game features
2. Check if each feature has tests
3. Assess test depth (happy path only vs edge cases)
4. Prioritize gaps by risk
---
## Step 4: Review Test Infrastructure
### Framework Health
- [ ] Tests run in CI
- [ ] Results are visible to team
- [ ] Failures block deployments
- [ ] Test data is versioned
- [ ] Fixtures are reusable
- [ ] Helpers reduce duplication
### Maintenance Burden
- How often do tests need updates?
- Are updates proportional to code changes?
- Do refactors break tests unnecessarily?
---
## Step 5: Generate Recommendations
### Priority Matrix
| Finding | Severity | Effort | Recommendation |
| --------- | -------------- | -------------- | -------------- |
| {finding} | {High/Med/Low} | {High/Med/Low} | {action} |
### Common Recommendations
**For Flaky Tests**:
- Replace `Thread.Sleep` with explicit waits
- Add proper synchronization
- Isolate test state
**For Slow Tests**:
- Move to nightly builds
- Optimize test setup
- Mock expensive dependencies
**For Coverage Gaps**:
- Prioritize P0/P1 features
- Add smoke tests first
- Use test-design workflow
**For Maintenance Issues**:
- Refactor common patterns
- Create test utilities
- Improve documentation
---
## Step 6: Generate Test Review Report
### Report Structure
```markdown
# Test Review Report: {Project Name}
## Executive Summary
- Overall health: {Good/Needs Work/Critical}
- Key findings: {3-5 bullet points}
- Recommended actions: {prioritized list}
## Metrics
### Test Suite Statistics
[Tables from Step 1]
### Recent History
[Pass rates, trends]
## Quality Assessment
### Strengths
- {What's working well}
### Issues Found
| Issue | Severity | Tests Affected | Fix |
| ----- | -------- | -------------- | --- |
| | | | |
## Coverage Analysis
### Current Coverage
[Feature coverage table]
### Critical Gaps
[Prioritized list of missing coverage]
## Recommendations
### Immediate (This Sprint)
1. {Fix critical issues}
### Short-term (This Milestone)
1. {Address major gaps}
### Long-term (Ongoing)
1. {Improve infrastructure}
## Appendix
### Flaky Tests
[List with failure patterns]
### Slow Tests
[List with durations]
### Disabled Tests
[List with reasons]
```
---
## Review Frequency
| Review Type | Frequency | Scope | Owner |
| ----------- | --------- | ------------------------ | --------- |
| Quick Check | Weekly | Pass rates, flaky tests | QA |
| Full Review | Monthly | Coverage, quality | Tech Lead |
| Deep Dive | Quarterly | Infrastructure, strategy | Team |
---
## Deliverables
1. **Test Review Report** - Comprehensive analysis
2. **Action Items** - Prioritized improvements
3. **Coverage Matrix** - Visual gap identification
4. **Technical Debt List** - Tests needing refactor
---
## Validation
Refer to `checklist.md` for validation criteria.
@@ -0,0 +1,203 @@
# Test Review Report: {PROJECT_NAME}
**Review Date**: {DATE}
**Reviewer**: {REVIEWER}
**Period Covered**: {START_DATE} to {END_DATE}
---
## Executive Summary
### Overall Health: {Good | Needs Work | Critical}
### Key Findings
1. {Finding 1}
2. {Finding 2}
3. {Finding 3}
### Recommended Actions
1. {High priority action}
2. {Medium priority action}
3. {Ongoing improvement}
---
## Test Suite Metrics
### Test Distribution
| Type | Count | % of Total |
| -------------------- | ----- | ---------- |
| Unit Tests | | |
| Integration Tests | | |
| Play Mode/Functional | | |
| Performance Tests | | |
| **Total** | | 100% |
### Execution Metrics
| Metric | Current | Previous | Trend |
| -------------- | ------- | -------- | ----- |
| Pass Rate | | | {↑↓→} |
| Avg Duration | | | {↑↓→} |
| Flaky Tests | | | {↑↓→} |
| Disabled Tests | | | {↑↓→} |
### Recent Run History
| Date | Passed | Failed | Skipped | Duration |
| ---- | ------ | ------ | ------- | -------- |
| | | | | |
| | | | | |
| | | | | |
---
## Quality Assessment
### Strengths
- {What the test suite does well}
- {Good patterns observed}
- {Areas of strong coverage}
### Issues Found
| Issue | Severity | Count | Example | Recommended Fix |
| ------------------ | -------- | ----- | ------- | --------------- |
| Flaky tests | High | | | |
| Slow tests | Medium | | | |
| Missing cleanup | Medium | | | |
| Hard-coded waits | Low | | | |
| Unclear assertions | Low | | | |
### Anti-Patterns Detected
| Pattern | Occurrences | Impact | Fix Effort |
| --------- | ----------- | ------ | ---------- |
| {pattern} | | | |
---
## Coverage Analysis
### Feature Coverage Matrix
| Feature | P0 Tests | P1 Tests | P2 Tests | Gap? |
| ------------- | -------- | -------- | -------- | ---- |
| Core Loop | | | | |
| Combat/Action | | | | |
| Movement | | | | |
| UI/Menus | | | | |
| Save/Load | | | | |
| Progression | | | | |
| Multiplayer | | | | |
| Audio | | | | |
| Platform | | | | |
### Critical Gaps
| Gap | Risk | Impact | Priority to Fix |
| ----------------------- | ------------ | ----------- | --------------- |
| {feature without tests} | {risk level} | {if breaks} | P{0-3} |
### Coverage by Priority
```
P0 Coverage: {X}% ████████░░
P1 Coverage: {X}% ██████░░░░
P2 Coverage: {X}% ████░░░░░░
P3 Coverage: {X}% ██░░░░░░░░
```
---
## Infrastructure Review
### CI/CD Integration
| Aspect | Status | Notes |
| ----------------- | ------- | ----- |
| Tests in CI | {✅/❌} | |
| Results visible | {✅/❌} | |
| Failures block | {✅/❌} | |
| Nightly runs | {✅/❌} | |
| Performance tests | {✅/❌} | |
### Test Infrastructure Quality
| Component | Quality | Notes |
| -------------- | ---------------- | ----- |
| Fixtures | {Good/Fair/Poor} | |
| Helpers | {Good/Fair/Poor} | |
| Data factories | {Good/Fair/Poor} | |
| Documentation | {Good/Fair/Poor} | |
### Maintenance Burden
- Test update frequency: {high/medium/low}
- Brittleness score: {high/medium/low}
- Developer friction: {high/medium/low}
---
## Recommendations
### Immediate (This Sprint)
| Action | Effort | Impact | Owner |
| ------------------------- | ------- | ------ | ----- |
| {fix critical flaky test} | {hours} | High | |
| {add P0 test for X} | {hours} | High | |
### Short-term (This Milestone)
| Action | Effort | Impact | Owner |
| ----------------------------- | ------ | ------ | ----- |
| {refactor slow tests} | {days} | Medium | |
| {add integration tests for Y} | {days} | Medium | |
### Long-term (Ongoing)
| Action | Effort | Impact | Notes |
| ----------------------------- | ------- | ------ | ----- |
| {improve test infrastructure} | {weeks} | High | |
| {expand coverage to Z} | {weeks} | Medium | |
---
## Appendices
### Appendix A: Flaky Tests
| Test Name | Failure Rate | Failure Pattern | Fix Priority |
| --------- | ------------ | --------------- | ------------ |
| | | | |
### Appendix B: Slow Tests
| Test Name | Duration | Type | Action |
| --------- | -------- | ---- | -------------------------- |
| | | | {optimize/move to nightly} |
### Appendix C: Disabled Tests
| Test Name | Disabled Since | Reason | Action |
| --------- | -------------- | ------ | ------------ |
| | | | {fix/delete} |
### Appendix D: Technical Debt
| Item | Description | Effort | Priority |
| ---- | ----------- | ------ | -------- |
| | | | |
---
## Next Review
**Scheduled**: {DATE}
**Focus Areas**: {areas to pay attention to}
**Success Criteria**: {what would make next review "green"}
@@ -0,0 +1,46 @@
# Game QA workflow: test-review
name: gametest-test-review
description: "Review test quality, coverage, and identify gaps in game testing"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/gametest/test-review"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
template: "{installed_path}/test-review-template.md"
# Variables and inputs
variables:
review_scope: "full" # full, targeted, quick
game_engine: "auto" # auto, unity, unreal, godot
# Output configuration
default_output_file: "{output_folder}/test-review-report.md"
# Required tools
required_tools:
- read_file
- write_file
- list_files
- search_repo
- glob
tags:
- qa
- review
- coverage
- quality
- maintenance
execution_hints:
interactive: false
autonomous: true
iterative: true