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

分岐ストーリーのテストは、「すべてのルートを一度ずつプレイする」だけでは完了しません。パスの数は急速に増え、多くの不具合は状態の組み合わせから生じます。より確実な方法は、まず状態遷移を検証し、次にリスクを優先したパスで重要な組み合わせをカバーし、最後に各不具合を回帰テストケースに変えることです。

読み取り箇所のない変数は削除し、値の出所がない読み取り条件には、その出所を補います。

各テストケースには、開始ノード、前提となる状態、操作、想定される次のノード、状態の変化、スクリーンショットまたはログを記録します。時間制限付きの選択では、タイムアウト、制限時間の境界での入力、連続クリックもテストします。メディアノードでは、読み込み失敗と復旧をテストします。

関係値の高低と鍵の所持、QTEの成功・失敗と手がかりの入手など、2つの変数の重要な組み合わせを優先してカバーします。高リスクな全組み合わせのテストを代替することはできませんが、比較的低いコストでよくある条件の誤りを発見できます。

標準のメインルート、各エンディングへの最短ルート、リソースが最も少ないルート、すべてのQTEに失敗するルート、セーブ／チャプターの復旧ルート、過去の重大な不具合に対する回帰テストルートです。

バージョン／プラットフォーム：
開始ノードと前提となる状態：
再現手順：
実際の結果／期待する結果：
発生頻度：
スクリーンショットまたはログ：

リリース前には、少なくともすべての重大な不具合がクローズされ、各エンディングを2回再現でき、セーブデータのアップグレードとチャプタージャンプが検証済みであることを確認し、未カバーの組み合わせに伴うリスクを明示します。

ストーリー図だけでテストすると、プレイヤーがAからBへ移動したことはわかっても、どの変数に値が書き込まれたかはわかりません。状態辞書では、変数の型、初期値、有効範囲、書き込みと読み取りのノードを定義します。変数名や範囲が変わるたびに、テストケースも更新する必要があります。

関係値は特に制御が難しくなりがちです。単に「信頼が増える」と書くのではなく、いくつからいくつになるのか、上限があるのか、どの場面で読み取るのか、画面でどうフィードバックするのかを記載します。エンディング条件が trust > 3 なら、境界値の3と4を両方テストする必要があります。

通常の選択に加えて、連続クリック、カウントダウンの境界での入力、ネットワーク切断、バックグラウンドへの切り替え、メディアの読み込み失敗、高速スキップ、言語の切り替え、セーブデータの復元もテストします。よくある不具合はストーリーの誤りではなく、異常な操作の後に状態が重複して書き込まれたり、まったく書き込まれなかったりすることです。

各テストケースは、再現可能なセーブデータから開始します。「第3章に入って左側をクリックする」だけでは再現に不十分です。第3章に引き継がれる関係値やアイテムが異なる可能性があるためです。

P0はメインルート、すべてのエンディング、セーブデータの破損、コンテンツの安全性をカバーします。P1は重要な関係、アイテム、QTE、チャプタージャンプをカバーします。P2は個別のセリフと低リスクな視覚的差異をカバーします。コミットごとにノードテストとP0のスモークテストを実行し、リリース候補版でP1/P2を実行します。

カバレッジは、訪問したノード数だけで報告しないでください。状態遷移、エンディング条件、異常時の復旧、未テストの組み合わせも報告します。ノードを訪問したことは、そのすべての条件が正しいことを意味しません。

問題を1つ修正するたびに、元の前提状態と操作を回帰テストの集合に追加します。チャプタージャンプ時の初期値が原因なら、今後のすべてのバージョンでその場面を検証する必要があります。そうしなければ、リファクタリング後に同種の誤りが再発します。

たとえば、プレイヤーがN05で鍵を入手したのに、N08へジャンプするとシステムが初期値の has_key=false を使ってしまう場合です。記録には、通常の全行程とジャンプを使った行程の比較、セーブデータのバージョン、ログを含めます。修正後は、新規セーブ、旧セーブ、チャプターのやり直しをそれぞれ検証します。

報告には、合格したエンディング、重要パス、リリースを阻む不具合、残存リスク、バージョンを列挙します。「全行程をテスト済み」のような、監査できない表現は使わないでください。目的はバグがないと宣言することではなく、どの因果関係を検証し、どの組み合わせがまだ不明なのかを意思決定者に伝えることです。

メインルートの初回クリア、課金への入口、取り消せない選択、最終エンディングは最高リスクに分類し、ビルドごとにテストします。よく使われるサブルートと主要な合流箇所は毎日回帰テストし、まれな組み合わせはバージョンごとに交代でテストできます。優先順位は、ユーザーへの影響、発生確率、修正コスト、過去の不具合を合わせて決めます。自動化しやすいルートだけをテストしてはいけません。

各テストケースには、初期セーブ、操作手順、期待する状態、目に見える結果、後処理の方法を明記します。失敗時には、ビルド番号、ノード、状態のスナップショット、スクリーンショットまたは動画、最短の再現パスを保存します。「たまに誤ったエンディングへ飛ぶ」としか説明できなければ、開発者は条件計算、セーブデータの移行、メディアの読み込みのどこに問題があるのかを特定しにくくなります。

状態の追加、ノード名の変更、初期値の調整を行う際は、リリース版の旧セーブを新しいビルドで読み込み、欠けたフィールドがどう補われるか、解放済みのコンテンツが保持されるか、以前のセーブに戻すことで重要な移行処理を飛ばしてしまわないかを確認します。新規セーブで合格しても、アップグレードが安全とは限りません。互換性を維持できない場合は、影響を事前に説明し、理解しやすい対処方法を提示します。

受け入れ会議では、証拠のある結果だけを扱います。どのパスを実行したか、どの状態の境界をカバーしたか、残る不足を許容できる理由は何かを確認します。未カバーの領域を明示することは、大まかな合格率ひとつで安心感を生み出すよりも価値があります。