はじめに
ゲームのQAがテスト業務で必要とするツールといえば、
- テスト対象のゲーム
- テスト項目書（Excel、スプレッドシートなど）
- バグトラッキングシステム（Redmine,JIRAなど）
- チャット/メール
などあるかと思いますが、QAにとって大事なツールがもう一つあります。
それがデバッグコマンドです。
(デバッグモード、チート機能とも呼ばれるかもしれません）
今回はゲームのデバッグコマンドについて書きたいと思います。
QAがどんな風に、どんなテストで使用しているのか、イメージを掴んでもらえればと思います。
基本のデバッグコマンド
キャラクターを付与する
アイテムを付与する
通貨を付与する
ユーザーのステータス（ランク、実績など）を調整する
イベントフラグ（進行度）を変更する
ゲーム内の時間を変更する
どんなジャンルのゲームでも、大抵これらのデバッグコマンドは実装されています。
デバッグコマンドではなく、ユーザー管理ツールから受け取りボックスを通じて付与する、といった場合もあります。
ゲーム内で獲得できる要素が自由に付与できれば、
各要素の単体テストは容易になります。
ステータスやフラグを変更できれば、
一度きりしか発生しないイベントのチェックも容易に行えます。
ゲーム内の時間が変更できれば、
実際の時間が関わるイベントのチェックができます。
様々な”状態”を作ることができますので、
まさに基本のデバッグコマンドと言えるでしょう。
ダミーデータのデバッグコマンド
フレンドを作る（または申請をもらう）
ギルドデータを作る
ランキングデータを作る
例えばそのゲームにマーケット機能があった場合、
セーブデータを新規作成し、ゲームを進め、アイテムを出品登録する・・・
といったことを１個１個手作業でやっていたらキリがありません。
リズムゲームのランキング機能でも同様ですよね。毎回１曲プレイするのは大変です。
ダミーデータとして大量かつ多種多様なデータを投入できれば
テストの準備に時間を取られることが無くなります。
UIのデバッグコマンド
ゲーム画面を拡大する・縮小する・移動させる
一部のUIだけを消す
当たり判定（コリジョン）を可視化する
タッチ判定領域を可視化する
テキストのIDを表示する
拡大したり余計なものが消せれば、
ゲーム画面の特定の箇所や見にくい箇所をチェックすることが容易になります。
当たり判定やタッチ判定を可視化できれば、
想定外の判定箇所を見つけることもできます。
テキストについては、
例えば 「はい」 というテキストはあらゆる画面で使用されるため、
識別するためにIDの表示は有用です。
演出再生のデバッグコマンド
指定のイベントシーンを再生する
指定のサウンドを再生する
指定のガチャ演出を再生する
指定のTIPSを再生する
進行度を自由に変えられても、ゲームを操作し特定の場所まで進めないと再生されない演出もあります。
フラグ達成によるイベントの発生をチェックするのではなく、
イベントの内容自体をチェックしたい場合は上記のデバッグコマンドが有用です。
インゲームのデバッグコマンド
味方または敵が無敵になる
味方または敵が一発で死ぬ
味方または敵のステータスを変更する
スキルが常時発動できる
キャラクターの場所を任意に移動できる
敵の動きを変える・止める
ゲームの速度を上げる・下げる・止める
確率を操作する
行動順（タイムライン）を可視化する
ダメージの計算式を可視化する（属性やスキル効果などの倍率の計算式が見れる）
キャラクターやステージのテストはもちろん、
スキルの単体テストなどでこれらのデバッグコマンドを駆使します。
見えない情報を可視化することもできれば、
ゲームがロジック通りに動作しているか確認することができます。
インゲームのデバッグコマンドは多種多様ですが、あればあるだけ便利です。
（余談ですがインゲームのデバッグコマンドが無い現場に配属されたことがありますが、
とにかく時間がかかって地獄でした。）
ハードウェアのデバッグコマンド
パケットロスを再現する
ストレージ空き容量不足を再現する
電池切れを再現する
位置情報を偽装する
これらを新規に実装する、ということはあまり無いかもしれませんが、
ソフトウェア側でも実装されていれば、割り込み処理の確認やダイアログのテキストチェックに使えるでしょう。
位置情報偽装は位置ゲーでは必須ですね。
【番外編】特に良かったデバッグコマンド
以下は番外編として、「これ便利だったな～」と思うデバッグコマンドを紹介します。
ワンボタンで、いい感じの進行状態・ステータスにしてくれる
自動でプレイしてくれる
ユーザーごとにゲーム内の時間を変更できる
１つ目ですが、ソーシャルゲームのQAでは、ユーザーを新規作成することが多いです。
その為、いちいち色々付与したり、進行度を変えたりするのが面倒になってきます。
ワンボタンで処理してくれるのは大変便利でした。
２つ目は、エージングテスト（放置テスト）やモンキーテスト（適当操作）としても利用できたりと、
多用な使い道が好みでした。
３つ目については、全てのオンラインゲームに必須で実装して欲しいくらいです。
他のメンバーの都合を考えたり、時間変更の順番待ちから解放されました。
【重要】デバッグコマンドが予め用意されているとは思わないこと
デバッグコマンドをいくつか紹介致しましたが、
そもそもQAがどんなテストをするのか、開発者は何も知りません。
QA：「エンディングのチェックをするぞ！」
QA：「でも毎回ボス戦クリアするの面倒だ！」
QA：「エンディングを再生する機能は・・・しまった！無かった！」
QA：「開発さん！この機能が欲しいのですが！」
開発：「・・・え、QA用に今から実装ですか？工数的に厳しいですね・・・」
と、言われてしまうことが、あるかもしれません。
大切なのは、QAが各機能の企画段階（開発着手前）で
“このテストが必要で、だけど自力でやるのは大変なので、このデバッグコマンドの実装をしてほしい”
という要望を出すことです。
QA以外の人間がテスト内容を把握していない、ということは結構あると思います。
QAが実施したいことを伝え、開発に協力を仰ぐことで、結果開発の効率を上げることができるのです。
ただ単に実装してくれ、ではなく理解が得られるまでコミュニケーションすることが大事です。
おわりに
ウチではこんなデバッグコマンドあるよ！便利だよ！
というものがあればコメント頂けると幸いです。
（デバッグコマンドでは無いですが、常にゲーム画面を録画できる環境もあると大変便利だなぁと思い出しました。）
今回記載したデバッグコマンドが当たり前の世の中になり、
QAから要望を出す前に考慮されていると お互いにとって とても幸せだと思います。