プレイヤーに届くビルドをテストしましょう。エディターで動くゲームでも、配布時にはアセットが欠けていたり、古いセーブデータが使えなくなっていたり、ストアの説明がパッケージの実際の内容以上のものを約束していたりすることがあります。テストを始める前に、リリース候補に固定の識別子を付け、簡潔なテストマトリクスを用意してください。
目指すのは、テスト済みのパッケージ、既知の問題の一覧、サポート用の記録という、役に立つ3つの成果です。ゲームのシステムと、対応すると明示した端末に合わせて確認項目を選びましょう。実装の詳細をなぞるだけの大規模なテストスイートでは、プレイヤーが遭遇する問題を見逃すことがあります。
識別できるリリース候補を凍結する
ソースのリビジョン、エンジンのバージョン、コンテンツのバージョン、想定する対象プラットフォームを記録してください。クリーンな作業環境からビルドするか、作業環境の状態を記録しましょう。テスト開始後に変更を加えた場合は、その影響を確認してください。一見無関係な編集でも、リリース準備中の候補に影響する可能性があります。
パッケージとそのチェックサムをリリースノートと一緒に保管してください。テスターには、テストした候補、使用端末、通ったルートを明記してもらいましょう。修正済みの開発用ビルドを、テスターが実際にテストしたパッケージと取り違えてはいけません。
重要なルートと状態を網羅する
すべてのエンディング、主要な排他的ルート、しきい値、必須のアンロックを網羅するマトリクスを作成してください。新規開始、選択肢の前後でのセーブとロード、再起動、古いセーブデータを含むサポート対象のアップデート時の状態をテストしましょう。ゲームが提供している場合は、スキップ、バックログ、ロールバックも対象に含めてください。エンディングが正常に動いても、途中のシーンのアンロックに不具合があってよいわけではありません。
繰り返されるイベントや、通常とは異なる状態から抜ける処理を確認してください。見た目には問題のないシーンでも、報酬を二重に付与したり、ルートのフラグに不整合を残したりすることがあります。開発中に見つかった不具合を対象を絞った回帰テストに組み込み、次の候補で同じバグが知らないうちに再発しないようにしましょう。
想定した操作体験を確認する
テスターに説明や誘導なしで操作してもらいましょう。会話のテンポ、メニューが伝える情報、読みやすさ、キーボード入力やタッチ操作、フォーカス、設定を確認してください。プレイヤーが次の操作を見つけられない箇所に注意しましょう。ボタンについてのあなたの説明は、ゲームに同梱されません。
音声の操作と、動きや再生に関する設定があれば、それらもテストしてください。必要に応じて、セッションの中断やバックグラウンドからの復帰も含めましょう。アクセシビリティ設定が各ルートやセーブシステムで安定して機能することを確認してください。設定画面に適切な切り替え項目があるだけでは、まだ確認の第一歩にすぎません。
パッケージ構成と外部依存関係を点検する
配布物をソースプロジェクトの外にインストールまたは展開し、そこから起動してください。ファイルの欠落、ファイル権限の問題、セーブ先の問題、必要なランタイム構成要素を確認しましょう。パッケージに開発用の秘密情報や不要なソースデータが含まれていないことも確認してください。
ブラウザー向けにリリースする場合は、実際のエクスポートを想定したホスティング環境で配信してください。アセットのパス、ストレージの動作、読み込みが遅い場合や失敗する場合を確認しましょう。ダウンロード版では、配布用アーカイブとインストール手順を対応するオペレーティングシステム上でテストしてください。プレイヤーに届くパッケージそのものも、テストの対象です。
公開する説明をビルドに合わせる
利用できるコンテンツ、対応言語、システム要件、エディション間の違い、既知の制限を正確に説明してください。配信先の現在の公開要件と、AI利用の開示要件を確認しましょう。公開用のプレビューには、配信先のコンテンツ規則に適合するものを選んでください。
プロトタイプを完成したゲームと呼んだり、推定値を実測に基づく要件として示したりしないでください。実際の内容を代表するスクリーンショットを使い、編集用のイラストを使う場合はその旨を明示しましょう。実際に利用する配布経路で必要となる決済とコンテンツの承認を、リリース前に得ておいてください。
復旧手段を用意してリリースする
候補、編集可能なソース、権利管理台帳、テストの証拠をアーカイブしてください。明確なバージョン情報、サポート窓口、既知の問題を公開しましょう。配布契約で認められる場合は、以前の使用可能なリリースも保管し、復旧のために記憶を頼りに古いビルドを再構築する必要がないようにしてください。
報告が届いたら、プロジェクト全体に大きな変更を加える前に、問題が起きたバージョンで再現してください。原因を修正し、関連する状態を確認して、回帰テストのマトリクスを更新しましょう。適切なサポートには、どのビルドが変更されたか、修正がどこまで対応しているか、何を検証したかを説明できることが必要です。
重要な決定事項
- パッケージ化した候補に固定のIDを付け、そのパッケージをテストしましょう。
- ルートの境界条件、必須のアンロック、サポート対象の古いセーブデータを網羅しましょう。
- 操作、配布、公開する説明をまとめて確認しましょう。
- リリースをアーカイブし、修正した不具合を回帰テストのマトリクスに追加しましょう。
ガイドのファイル
リリースチェックリスト ↓テストマトリクス ↓外部のモデル関連コミュニティやコンテンツ公開サイトには、露骨な表現を含むコンテンツが掲載されている場合があります。出典へのリンクは新しいタブで開きます。このガイドでは、リンク先のプレビューを読み込みません。