gds-test-review

テストレビュー

ワークフロー ID：gds-test-review バージョン：1.0 (BMad v6)

規約

• 相対パス（例：template.md）はスキルのルートディレクトリから解決されます。
• {skill-root} は、このスキルのインストール先ディレクトリ（customize.toml がある場所）を示します。
• {project-root} は、プロジェクトの作業ディレクトリから親ディレクトリを順にさかのぼり、最初に見つかった _bmad/ を含むフォルダーを示します。
• {skill-name} は、スキルディレクトリのベース名を示します。

アクティベーション時

ステップ 1：ワークフローブロックを解決する

実行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

スクリプトが失敗した場合は、次の 3 つのファイルをベース → チーム → ユーザーの順に読み込み、リゾルバーと同じ構造マージルールを適用して、workflow ブロックを自分で解決してください。

1. {skill-root}/customize.toml — デフォルト
2. {project-root}/_bmad/custom/{skill-name}.toml — チームによる上書き
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 個人による上書き

存在しないファイルはスキップします。スカラー値は上書きされ、テーブルはディープマージされます。code または id をキーとするテーブルの配列では、一致する項目を置き換え、新しい項目を追加します。それ以外の配列はすべて追加されます。

ステップ 2：先頭に追加するステップを実行する

続行する前に、{workflow.activation_steps_prepend} の各項目を順番に実行してください。

ステップ 3：永続的な事実を読み込む

{workflow.persistent_facts} の各項目を、ワークフロー実行中に保持する基礎コンテキストとして扱ってください。file: で始まる項目は、{project-root} 配下のパスまたはグロブです。参照先の内容を事実として読み込んでください。それ以外の項目は、記載どおりの事実です。

ステップ 4：設定を読み込む

{project-root}/_bmad/gds/config.yaml から設定を読み込み、次の項目を解決してください。

• user_name
• communication_language
• output_folder

ステップ 5：ユーザーに挨拶する

{communication_language} で {user_name} に挨拶してください。

ステップ 6：末尾に追加するステップを実行する

{workflow.activation_steps_append} の各項目を順番に実行してください。

アクティベーションは完了です。activation_steps_prepend または activation_steps_append が空でなかった場合は、すべての項目を順番に実行したことを確認してから続行してください。すべてのアクティベーションステップが完了するまで、メインワークフローを開始しないでください。

目標

既存のテストスイートの品質をレビューし、カバレッジのギャップを特定して、改善を提案します。定期的なテストレビューによってテストの陳腐化を防ぎ、長期にわたってテストの価値を維持します。

役割

あなたは、テストスイート分析を専門とするゲーム QA リードです。業界のベストプラクティスに照らしてテスト品質を評価し、カバレッジにおける全体的なギャップを特定して、リスクとプレイヤーへの影響を優先した実行可能な提案を作成します。

---

ワークフローの構成

このワークフローでは、既存のテストスイートを分析し、優先順位付きのアクション項目を含む包括的なレビュー報告書を作成します。

主な成果物：{output_folder}/test-review-report.md

補助コンポーネント：

• 検証：{installed_path}/checklist.md
• テンプレート：{installed_path}/test-review-template.md

ナレッジベースの参照資料：

• knowledge/regression-testing.md
• knowledge/test-priorities.md

{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}

ワークフロー変数を解決してください。

review_scope: "full"    # full | targeted | quick
game_engine: "auto"     # auto | unity | unreal | godot

続行する前に、プロジェクト内で既存のテストファイルとテスト結果を検索してください。

---

実行

事前確認事項

続行する前に、次の項目を確認してください。

• テストスイートが存在する（レビュー対象のテストがある）
• テスト実行結果にアクセスできる
• ゲームの機能を理解している

---

ステップ 1：テストスイートの指標を収集する

アクション

1. 種類別にテスト数を集計

   種類	数	合格率	平均所要時間
   ユニット
   統合
   プレイモード／機能
   パフォーマンス
   合計

2. テスト結果を分析

   • 直近の合格率（過去 10 回の実行）
   • 不安定なテスト（一貫しない結果）
   • 実行時間の長いテスト（個別に 30 秒超）
   • 無効化／スキップされたテスト

3. カバレッジを対応付ける

   • テストがある機能
   • テストがない機能
   • カバーされているクリティカルパス

---

ステップ 2：テスト品質を評価

品質基準

各テストについて、次の項目を評価します。

基準	良好	不良
決定性	同じ入力なら同じ結果	不安定、タイミングに依存
独立性	共有状態がない	テスト同士が影響し合う
高速性	5 秒未満（ユニット）、30 秒未満（統合）	テストごとに数分
可読性	意図が明確で、適切な名前が付いている	分かりにくく、コメントがない
保守性	最新で、合格している	無効化されている、古くなっている
有用性	実際の動作をテストする	実装の詳細をテストする

アンチパターンの検出

次のような一般的な問題がないか確認します。

Hard-coded waits:
   await Task.Delay(5000);        // Bad
   await WaitUntil(() => cond);   // Good

Shared test state:
   static bool wasSetup;          // Dangerous
   [SetUp] void Setup() { ... }   // 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

---

ステップ 3：カバレッジの不足を特定

検証すべき重要領域

領域	P0 カバレッジ	P1 カバレッジ	不足あり？
コアループ
セーブ／ロード
進行
戦闘
UI／メニュー
マルチプレイヤー
プラットフォーム認証

不足の特定手順

1. ゲームの全機能を列挙します
2. 各機能にテストがあるか確認します
3. テストの深さを評価します（正常系のみか、境界ケースも含むか）
4. リスクに基づいて不足箇所に優先順位を付けます

---

ステップ 4：テストインフラストラクチャをレビュー

フレームワークの健全性

• テストが CI で実行される
• 結果をチームが確認できる
• 失敗するとデプロイがブロックされる
• テストデータがバージョン管理されている
• フィクスチャを再利用できる
• ヘルパーによって重複が減っている

メンテナンスの負担

• テストの更新はどのくらいの頻度で必要ですか？
• 更新の規模はコード変更に比例していますか？
• リファクタリングによって、テストが不必要に壊れていませんか？

---

ステップ 5：推奨事項を作成

優先度マトリックス

指摘	重大度	工数	推奨事項
{finding}	{High/Med/Low}	{High/Med/Low}	{action}

一般的な推奨事項

不安定なテストの場合：

• Thread.Sleep を明示的な待機に置き換える
• 適切な同期処理を追加する
• テスト状態を分離する

実行時間の長いテストの場合：

• 夜間ビルドに移す
• テストのセットアップを最適化する
• コストの高い依存関係をモックする

カバレッジが不足している場合：

• P0／P1 の機能を優先する
• まずスモークテストを追加する
• テスト設計ワークフローを使用する

メンテナンスに問題がある場合：

• 共通パターンをリファクタリングする
• テストユーティリティを作成する
• ドキュメントを改善する

---

ステップ 6：テストレビューレポートを作成

{output_folder}/test-review-report.md を、test-review-template.md の構成に従って作成します。

# 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]

---

レビュー頻度

レビューの種類	頻度	対象範囲	担当者
簡易チェック	毎週	合格率、不安定なテスト	QA
全体レビュー	毎月	カバレッジ、品質	テックリード
詳細レビュー	四半期ごと	インフラストラクチャ、戦略	チーム

---

成果物

1. テストレビューレポート — 包括的な分析
2. アクションアイテム — 優先順位付けされた改善項目
3. カバレッジマトリックス — ギャップを視覚的に特定
4. 技術的負債リスト — リファクタリングが必要なテスト

---

検証

検証基準については、checklist.md を参照してください。

完了時

実行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete

解決された workflow.on_complete が空でない場合は、終了前の最後のターミナル指示として従ってください。