分岐ストーリーのテスト方法：パスカバレッジ、状態マトリクス、回帰テスト

分岐ストーリーのテストは「すべてのエンディングを一度ずつプレイする」だけでは不十分です。ひとつのエンディングには複数の状態から到達でき、同じノードでも関係性、証拠、リソースによってエラーが発生します。実行可能な方法は、段階ごとにカバレッジを確保することです。まずグラフ構造を自動チェックし、次に重要な状態の組み合わせをテストし、最後に代表的なパスで映像と音声を含む体験全体を検証します。

ゲームを実行せずに、ノードIDが一意であること、すべての出口が存在すること、エンディング以外のノードに出口があること、開始ノード以外のノードに入口があること、変数の型が正しいこと、ローカライズキーとメディア参照が揃っていることをチェックします。孤立したノード、行き止まり、明らかに満たせない条件、読み取られていない状態を報告します。

静的チェックは高速で、コミットごとの実行に適しています。物語が面白いことを証明はできませんが、テスターが映像を見る前に、多くの表記ミスや参照エラーを検出できます。

各選択肢について、前提条件、書き込み結果、遷移先ノードを検証します。既知の初期状態から選択を送信し、関係性、証拠、リソース、世界の状態が正しく変化することをアサーションで確認します。繰り返し送信しても報酬が重複して付与されないこと、タイムアウトと入力なしの場合に指定のルートへ進むことも確認します。

名前の付いた複雑なルールは、ケースを分けてテストします。例えば can_publish_truth では、証拠不足、信頼度の低さ、リソース不足、すべての条件を満たす場合をそれぞれ検証します。境界値は特に重要です。関係性のしきい値の上下1段階、リソースが0と1の場合、集合の要素がちょうどひとつ不足している場合を確認します。

すべての変数の全組み合わせをテストするのは、通常は現実的ではありません。まず、同じノードに共同で影響する変数を特定し、ペアワイズまたはリスクに基づく組み合わせを使って、重要な値のすべてのペアが少なくとも一度は同時に現れるようにします。エンディング、決済、セーブデータの移行、不可逆な状態など、リスクの高い領域では、3要素の組み合わせや網羅的なテストを追加します。

状態マトリクスは1行につき1つのテストケースとし、初期値、パス、表示されるはずの選択肢、メディアのバリエーション、最終状態、エンディングを記載します。「信頼度が低い場合をテスト」とだけ書かず、再現可能な値とバージョンを必ず示します。

少なくとも、最短のメインストーリーパス、証拠が最大の場合、関係性が最低の場合、リソースの枯渇、全編タイムアウト、補助モード、チャプター移動、旧セーブデータの移行をカバーします。全編を視聴して、物語の因果関係、演技、字幕、音声、シームレスな切り替えをチェックします。これらは単体テストでは発見できません。

パスごとに訪問ログを生成し、想定するノードの順序と比較します。ずれが生じたときに、エンディングで初めて結果の誤りに気づくのではなく、最初に分岐がずれた箇所を特定できるようにします。

報告には、ビルドバージョン、プラットフォーム、言語、セーブデータのバージョン、開始ノード、主要な変数、操作手順、実際の結果と期待する結果、メディアID、ログ、スクリーンショットまたは画面録画を記載します。「第3章で誤ったエンディングに入った」とだけ書いても、ほぼ再現できません。

匿名の状態スナップショットをエクスポートできるデバッグパネルを用意します。ただし、実際のプレイヤーデータはプライバシー上の制約を守る必要があります。テストツールでノードへ直接移動できても、定期的に実際の前段のパスから入る必要があります。直接移動すると、状態の書き込みが抜ける可能性があるためです。

ノードの出口を変更した場合は、そのノードに入るすべての代表的な状態と、その先の重要なルートをテストします。共有動画を変更した場合は、それを参照するすべてのパスを確認します。基礎となる変数を変更した場合は、それを読み取るすべてのノードへ範囲を広げます。「ノード—変数—アセット—テスト」の追跡関係を維持すれば、回帰テストの集合を自動で提案できます。

不具合が発生したルートだけを再テストしてはいけません。修正によってエラーが別の入口に移ることはよくあり、特にパスの合流やセーブデータの復元で起こります。

リリースを阻止する問題には、メインストーリーに到達できないこと、状態の破損、セーブデータの消失、黒い画面でのフリーズ、重要な字幕の欠落が含まれます。重大度、優先度、対応の延期を認める基準は、テスト前に定義します。リリース候補ごとに、テスト報告、未解決の問題、リスクの承認記録を保存します。

カバレッジは、ノード、選択肢、状態のペア、メディア、エンディングについて集計できますが、数値そのものが品質ではありません。ノード訪問率が100%でも、すべての論理的な組み合わせが正しいとは限りません。報告には、カバーされていないリスクも記載する必要があります。

ヘッドレスランナーは、ノードの巡回、状態の注入、アサーションの検証、パスの生成を高速に行えます。端末の自動化では、起動、ダウンロード、セーブをテストできます。人によるテストは、選択肢の理解、演技の連続性、映像と音声のテンポ、感情の因果関係に集中します。ブール値ひとつを確認するためだけに、テスターに同じ10分間を何度も見せないようにします。

重要なバージョンごとに、最小限のセーブデータ一式を保存します。チャプターの入口、重要なしきい値の直上と直下、リソースが枯渇した状態、主要な各エンディングの直前、旧モードを含めます。サンプルにはコンテンツのバージョンと期待する結果を明記し、テスターが手作業で自由に変更しないようにします。ビルド完了後にまとめて読み込み、移行と、隠れた条件にずれがないことの両方を検証します。

テストアカウント、分析環境、本番環境を分け、巡回スクリプトがプレイヤーデータを汚染しないようにします。再現用のログやセーブデータに端末またはアカウント情報が含まれる場合は、プロジェクトのプライバシールールに従って、識別情報の除去、権限付与、削除を行います。

次のステップ：1章分の状態マトリクスを作り、まずすべてのノードと選択肢を自動チェックしてから、代表的なパスを6本選んでエンドツーエンドで視聴します。すべての不具合を、影響を受ける変数と回帰テストの集合に関連付けます。