はじめに
みなさまおつかれさまです。
今年のアドベントカレンダーも半分以上が過ぎ、本カレンダーにも様々な記事が投稿されました。
昨年に続き、カスタマーサポートや法的側面からの審査といった視点の記事がまとまっておりますので、まだ読まれていない方はぜひご覧ください。
本記事では、モバイルゲームにおけるテスト設計について実体験をもとにまとめてみました。
会社やプロジェクトによって差分はあると思いますが、少しでも参考になると幸いです。
テストアーキテクチャ設計とは
本記事内では詳細な説明は省略しますが、テスト要求分析とテスト詳細設計の間の位置づけで、どうやってやりたいテストを実現するのかを考えるフェーズと考えています。
テストの観点としては、「どういうバグを見つけたいか」と「どこにバグがあるのか」を組み合わせたもので、それらを階層構造やフレームなどでグルーピングして整理していったりします（下図参照）。
この工程により、何をどうテストするのかが具体化されていき、テストや仕様の考慮漏れを早期に検知できたりもします。以降の段落でモバイルゲームにおけるテストアーキテクチャ設計について説明していきます。
ゲーム開発現場の状況
本題に入る前に、本記事における前提部分を記載します。
これまで8年以上ゲーム開発に関わっていますが、ゲーム開発の現場は年々変化していると感じます。プロジェクトごとに特色も異なり、それぞれにあわせたテスト戦略が必要です。ここでは少しピックアップして特色をまとめてみます。
開発サイクル
モバイルゲームにおいては、プロジェクトの大規模化が進んでいます。ものにもよりますが、機能や表現が多様化して開発が複雑になってきているのが実態としてあり、最近では1本のゲームを開発するのに仕込みから数年かかることもざらです。
リリース後の開発自体は更新タイミングにあわせてバージョンを区切り、各バージョンごとに進行するようなかたちが多いと思います。各バージョン内にはそのタイミングで実装する新機能や不具合の修正、追加するイベントなどが含まれます。いつまでに何をリリースするのかを厳密に管理しつつ、並行して開発が進むようなイメージです。
明確にアジャイル開発というわけではないですが、動くものベースで関係者間で対話しつつイテレーションしていくようなケースも増えてきていると感じます。
仕様書
仕込み期間が長く、複雑なものは仕様書を作成することが多いです。細かい変更は、チャットのログやチケットで管理することもあります。定型的なイベントなどはベースとなる仕様を流用し、更新箇所をハイライトする方法で運用コストを抑えたりします。
ゲームではゲーム自体の仕様に関する暗黙知も多いため、新規仕様が追加される際には暗黙知にも注意が必要です。このあたりを読み解くにはゲーム自体のドメイン知識がとても重要になります。
テストの状況
前述のようにプロジェクトが大規模化し、ゲームが複雑化してきているため、テスト設計に必要な工数も増加してきています。また、並行開発により同時に様々なテストが稼働するので、スピーディーにテストを作成しなければいけません。
一方で、短期間に十分なテストを設計するためのテスト担当者が不足しがちなので、開発スケジュールを確認しつつ早めに人員を確保できるように調整が必要です。
ゲームにおけるテストアーキテクチャ設計
前置きが長くなりすみません。ここからが本題です。
短期間で効率よくテスト設計するにはどうしたら良いか？私個人の見解をまとめてみました。
仕様を整理し、把握しましょう
ここでいう仕様は新規というよりゲーム自体の仕様を指します。仕様を把握する、当たり前のことではありますが、これを継続するのが実は難しかったりします。
モバイルゲームはリリースしたら終わりではなく、リリースしてからも運営が継続します。そのため、機能の追加や変更が日常茶飯事です。継続的に自身でも触っていないとすぐにわからなくなってしまいます。
とにかくゲームをプレイしてみることをおすすめします。
ベースとなるゲームの仕様を知っているかどうか、これはテストを考えるとき（あるいはレビューするとき）に、その作業精度を左右する重要な要素となります。テストアーキテクチャ設計時には、「新規機能追加時に既存機能に影響しないか」「新規パラメータと既存パラメータの組み合わせに漏れがないか」や、「効果範囲がどこまで及ぶか」などを考えたりする助けにもなったりします。
テスト観点を考えてみましょう
これもテスト設計をしたことがある方からしたら当たり前の話ではありますが、モバイルゲームでテスト観点を考える上で難しいと感じる点として、機能が多種多様（しかもジャンルが変わればけっこう違う）で、追加や変更により細かく変動することがあげられます。そのため、機能にあわせてその都度用いる観点を適用するのが難しかったりします。
それ以前にテスト観点の引き出しが少ないと考えることもできません。ある程度共通化できるところもあるので、そのあたりは汎用的なテスト観点としてまとめておくと良いと思います。
適用例
色々書いてみましたが、自身がわかりやすい（説明しやすい）ことが一番大事だと思います。ここでは箇条書きと表形式でまとめたときの例を記載してみます。
仕様サンプル
前提（ゲームとしての仕様）
- バトルに参加するチームの編成は前衛と後衛があり、敵との戦闘は前衛が行う
- 前衛と後衛はバトル中に交代することができる
- スキルには、自身で選択して使用するアクティブスキルと、バトル開始時/交代時に自動で使用されるパッシブスキルがある
- スキルには、味方の能力を上げるバフ、敵の能力を下げるデバフ、敵を攻撃するアタックスキルなどがある
仕様
- 味方にかけるアクティブスキルのバフの効果を上げるパッシブスキルを追加する
- 発動先はパッシブスキルを保持しているキャラクター自身とする
この仕様から、どういうバグを見つけたいのか、どこにバグがあるのかを整理していきます。
箇条書きでの整理例
見つけたいバグを箇条書きにしてみます。
- 発動先が正しいか（自分以外にかからないか）
- 発動タイミングは正しいか
- 効果の適用範囲が正しいか
- 効果が正しいか
次にどこにバグがあるのかを箇条書きにしてみます。
- 発動先：自身、メンバー、敵
- 発動タイミング：バトル開始時、交代時（再度交代時なども含む）
- 効果の適用範囲：攻撃バフ、防御バフ、攻撃デバフ、防御デバフ
- アクティブスキルの対象：味方全体、味方前衛、味方後衛、味方単体、敵全体、敵単体
- 効果：スキル発動時/未発動時、単発か永続か
表形式の整理例
こちらは一部抜粋して書いてみます。
| スキル種別 | 対象 | 属性 |
|---|---|---|
| 攻撃バフ | 味方全体 | 通常攻撃 |
| スキル攻撃 | ||
| 必殺技 | ||
| 味方前衛 | 通常攻撃 | |
| 以下略 |
表形式だとありえない組み合わせなども出てきますが、それも含めて全体を漏れなく抽出しやすくなるので、どこまで考慮すればよいかを洗い出すときなどに有効だと思います。
あくまで一例ではありますが、割りとシンプルなまとめ方を紹介してみました。前述したように、テストの全体像が見えやすくなることでテストや仕様の考慮漏れを早期に検知できるので、まだやったことない方はぜひ試してみてください。
実際にやってみて感じたこと
前提部分に記載したとおり、ゲームの開発は「複雑化が進み」「同時並行で複数の開発が走り」「短い期間でリリース」がされていきます。こうした開発サイクルにあわせたテストを実現するには、テスト設計もまた短期決戦的にスピード感を持って進める必要があります。
私がゲーム業界でテストをしていてテスト設計の要点について改めて思ったことは①ゲーム自体を理解する（ドメイン知識超大事！）②仕様を把握することにつきます。
テストを仕事にされている方には釈迦に説法ですが、短期間でテストを設計するにはこの2点が必須だと思っています。そのためには、まずゲーム自体をしっかりプレイして（開発中であれば開発中のビルド）ゲーム自体の理解を深めること、さらに仕様を整理して把握しやすい自身の型（階層で整理したり、図表をつかってみたり）を身につけることが重要です。本記事はほんのさわりではありますが、仕様のかたちが様々で一つのゲームの中にまったく違うゲーム性のコンテンツが入っていたりするゲームの世界はとても深く、テスト設計のかたちも色々出てくるのではと思っています。本記事を読んで、こういうのやってますという方がおられましたらぜひコメントいただけますと幸いです。（記事書いてみましたとかあると最高です。）
今後の課題
モバイルゲームの開発はまだまだ複雑になっていくと思います。その中で、今まで以上にテスト設計者の不足が懸念されます。どのように育成していくか、また評価していくかをしっかりと考えていかないといけません。このあたりは引き続き検討をすすめていきたいと思います。