リリース前はバグだけをテストしない：アクセシビリティ、低スペック、中断、入力デバイスのテスト

リリースの受け入れテストでは、物語を最後まで進められることの確認だけでは足りない。対象プレイヤーが実際のデバイスで、現実の中断を挟み、能力の違いがある条件でも中核となる体験を完了できることを示す必要がある。テストマトリクスには、少なくともアクセシビリティ、最低動作環境、ネットワークとシステムによる中断、入力デバイス、言語、セーブデータの復旧を含め、各項目の合格基準を定義する。

最低、推奨、ハイエンドの構成を挙げ、異なるCPU、GPU、メモリ、ストレージの種類、解像度、OSのバージョンを網羅する。純粋な3D性能よりも動画のデコード能力が重要なため、一部のハードウェアデコードをサポートしない境界ケースのデバイスも含める。モバイルでは、発熱、バックグラウンド処理の方針、ノッチ、システムジェスチャーもテストする。

各分類から少数の代表的なデバイスを選び、継続的に回帰テストを行う。際限なく機種を増やすことは目指さない。起動時間、最初のフレームが表示されるまでの時間、切り替え時間のP95、フレーム落ち、ピークメモリ使用量、ディスク使用量、消費電力を収集し、同じシナリオでバージョンを比較する。

テスターに、字幕を読む、選択肢を理解する、制限時間内に選ぶ、QTEを実行する、メニューを移動する、フォーカスを識別する、設定を変更するというタスクを行ってもらう。文字サイズと背景の調整、話者の識別、非言語音、色に頼らない代替手段、入力の再割り当て、連打の代替手段、制限時間の補助、音量の個別調整を確認する。

対象プラットフォームの現行要件に従い、シミュレーターだけで推測せず、関連する利用経験のある人にテストへ参加してもらう。Xboxアクセシビリティガイドラインは機能別の確認観点を提供しており、認証ではなく出発点として利用できる。Xboxアクセシビリティガイドライン

動画の準備、選択肢の表示、選択の送信、セーブデータの書き込み、リソースのダウンロード、チャプターの切り替え、エンディングの結果処理という各段階で強制終了する。復旧後は明確な位置に戻り、状態の重複や欠落がなく、メディアと字幕が同期している必要がある。画面ロック、バックグラウンドへの切り替え、着信、スリープ、コントローラーの切断、ストレージ容量の枯渇もテストする。

ネットワークのテストには、オフライン起動、不安定な通信、切断、再接続、ダウンロードの検証失敗、サービス利用不可を含める。シングルプレイのコンテンツは、分析サービスの障害でプレイできなくなってはならない。ネット接続が必須の機能では、理解できる理由と再試行方法を示す必要がある。

キーボードとマウス、ゲームパッド、タッチスクリーン、支援入力について、それぞれナビゲーション、フォーカス、戻る操作、一時停止、長押し、ダブルクリックの重複入力防止、使用中のデバイス切り替えを確認する。画面上のボタン表示は現在のデバイスに合わせて更新するが、頻繁な誤切り替えを防ぐデバウンス処理も必要となる。すべての中核操作は、小さな対象を正確にタッチしなくても実行できるようにする。

時間制限付きの選択中にゲームパッドが切断された場合、タイマーを止めるのか、時間を延長するのか、デフォルトのルートへ進むのかを必ず定義する。どの方式でも、一貫性があり、テストできる必要がある。

最長のテキスト、文字種の混在、欠落したグリフ、改行、字幕と選択肢の重なりを確認する。ウィンドウ表示、全画面表示、複数モニター、ウルトラワイド画面、スケーリング、異なるテレビのセーフエリアをテストする。HDRとSDRの両方をサポートする場合は、黒レベル、字幕の明るさ、画面録画の結果を確認する。

音声と字幕の組み合わせを自由に切り替えられる場合は、設定を保存し、チャプター移動後もリセットされないことを検証する。テキスト読み上げやスクリーンリーダーのサポートが範囲に含まれる場合は、コントロールの意味情報とフォーカス順序を確認する。

複数のチャプターを続けてプレイし、セーブデータを繰り返し読み込み、頻繁に言語を切り替え、ループして再プレイしながら、メモリリーク、キャッシュの肥大化、温度、セーブデータの増大を観察する。新品のマシンへのインストールだけでなく、旧バージョン、残存キャッシュ、複数のセーブデータがあり、ディスクの空き容量が少ない「汚れたデバイス」でもアップグレードする。

テストでは現実の一時中断を再現する。選択画面で30分間止める、翌日に再開する、システム時刻を変更するといった状況だ。インタラクティブ動画のステートマシンは、こうした境界で問題を露呈することが多い。

「低スペックでテスト済み」だけでは不十分だ。対象デバイスで指定ルートを連続して完了できること、切り替えの指標がしきい値を超えないこと、進行を妨げる問題がないこと、セーブデータの検証に合格することを記述する。修正できない制約については、ストアの動作環境と既知の問題を更新し、プレイヤーがリスクを発見するまで放置してはならない。

リリース候補を凍結した後は、評価を経た変更だけを受け入れる。メディア、字幕、設定の差し替えは、いずれも対応する回帰テストの実施につなげる。最終ビルドをクリーンな環境に一度インストールし、アンインストール、更新、オフライン起動を検証する。

プロジェクトに触れたことのない人に、リビングのテレビ、通勤中のスマートフォン、一般的なパソコン環境で指定タスクを行ってもらい、チームはそばでヒントを出さない。字幕と制限時間の設定を見つけられるか、ゲームパッドの切断後にどう復旧するか、現実の用事で中断した後に自分の進行位置がわかるかを記録する。開発チームはインターフェースに慣れているため、欠けている案内を無意識に補ってしまうことが多い。

発見した問題を、進行不能、明確な障害、好みに分け、影響を受ける人々と代替経路を記す。少数のテスターしか遭遇しなかったという理由で無視してはならず、すべての個人的な好みをリリース阻止の問題に格上げしてもならない。基準は、中核タスクを完了できるかどうかと、明示したサポート範囲に基づく。

次のステップ：「デバイス × 中断箇所 × 入力 × 言語」でリスクマトリクスを作り、問題が起きる可能性が最も高い20の組み合わせを選ぶ。リリース候補で各項目の証拠を記録し、合格のチェックを付けるだけで済ませない。