最終更新日: 2024年2月19日

今回の記事では、第三者検証サービスを行う企業が、パイロットプロジェクトにおいて自動ゲームテストを導入する際、ゲームのジャンルごとの実装難易度についてご紹介させていただきます。そのため、開発会社部署内で行える自動ゲームテストでの構築とは想定される状況が異なることをご留意いただければ幸いです。

1.自動化をする目的を間違えない

まず誤ってはいけない肝心な最初の一歩として、「どうしてテスト自動化をするか」について向き合う必要があります。
「テストを自動化する」ことだけを目的として導入した場合は、手動で行うテストよりも効果的なテストが実行できず、失敗する確率が跳ね上がることを意識した方が良いでしょう。

ゲームテストでもそうですが、一般的なソフトウェアテストの目的は「規定したテスト内容で問題がないことを確認する」、「品質目標に到達するようにテストを行う(そして不具合を検出する)」ことにあります。自動ゲームテストはあくまでも開発プロセス全体で品質を向上させる手段の一つと認識し、従来行っているテストに対してどのような効果が見込めるかを考慮しつつ、導入を検討することが大切です。

2.状況に応じた自動ゲームテストでのツールの選定

ゲームには様々なプラットフォームがあるため、既存の自動テストツールでも、テスト自動化をすることが可能な場合があります。自動ゲームテストに活用可能なテスト自動化ツールは多数ありますが、その中でも、導入を検討している段階で検索・調査していると見かけるであろう代表的なテストツールは、現状、以下のものです。

・Sikulix
・Selenium
・Appium
・mabl
・MagicPod
・Autify
・Device Farmer(STF)
・Airtest

余談ですが、テスト対象がHTML5ゲームであれば一部RPAツールも活用可能かもしれないので、そちらも調査をしてみるのも良いかもしれません。

ゲームテスト自動化の導入実績があまりない会社の場合、以下のような障壁があると思います。

・コーディングスキル不足(プログラムに触れたことがある人がいない)
・ICTリテラシーの不足により適するテストツールが見つからない
・自動化を導入するPCのスペックが不足しているためテストツールが十全に動かない
・予算の都合で「無料」しか選択できない

ゲームテストの導入を行う際、予算・環境があれば、「mabl」「Magic Pod」「Autify」のようなAIと機械学習を利用した自動テストツールを使用すれば解決できるとは思いますが、予算次第では無料のツールしか選択できない場合もある為、パイロットプロジェクトではそれも叶わないこともあるでしょう。

パイロットプロジェクトでは、小規模で開始した方が、失敗したときに影響が小さく自動化アレルギーにならずに済むと思いますので、今回は以下の条件を元にゲームテスト自動化の導入を想定していきます。

・可能な限り無料・トライアルで長期的に使える
・マウス一つでプログラミングが可能
・多様なプラットフォームで自動操作をすることができる

上記状況下では、非エンジニアでもテストツールを容易かつ柔軟に作成が出来る「Airtest」が有力候補に挙がると考えています。
理由としては、画像認識でのテストツールであれば、動かすまである程度直感的にテストスクリプトが作成できるため、最初に使用するテストツールとしては適していると考えらるためです。画像認識ではない自動化ツールの場合、テストする対象によっては要素の取得が不可能、または要素という概念を理解し記述するまでの学習コストが発生します。またもう一つの理由として、「Airtest」はマルチプラットフォームかつマウス一つでテスト実装・実行が可能で、実行後のログの出力も容易でエビデンスが取得しやすいためです。

「Airtest」の概要についてはQiitaの記事にて紹介をしているので詳細はこちらをご覧ください。
「Airtestでほぼ円状にスワイプしてみる」

3.「Airtest」での各ゲームジャンル毎の実装難易度とパイロットプロジェクトで実装すべきテスト実装内容

さて、テスト自動化ツールを選定しましたが、「Airtest」には以下の特徴があるため、自動テストを実装しようとすると、ゲームのジャンル、あるいは機能毎に実装の難易度が異なります。

・予めキャプチャした画像を元に自動テストを進める
・Airtestでの機能「Poco」（※）に対応できないソフトの場合、要素の取得が出来ない。
（※）PocoはAirtest内にあるゲーム開発プラットフォームでのUI周りのテストフレームワークです。Pocoの対応プラットフォームはiOS/Androidを初め、Cocos-2dx、Unity等のテスト実装ができます。例えばUnityは要素の取得して階層の情報や定のUIのオブジェクトを参照し動作させることが可能です。Pocoを使用するには、アプリケーション側でSDKの導入の対応が必要になる為導入するのは少し難しいでしょう。

筆者中嶌が様々なゲームジャンルで自動化テストの導入を試してみましたが、難易度のイメージマップをまとめると以下になります。

テスト自動化ツール　実装難易度のイメージマップ

パイロットプロジェクトでの実装を行う場合は、以下のテスト実装が容易だと思いますのでこれらをお勧めします。

・アウトゲームでの遷移テスト
・ガチャの実行
・アドベンチャーパートのあるゲームで読み進める

理由としては以下が挙げられます。

・画像を検知して進むことができる
・操作手順が簡単なものが多い
・繰り返し使いまわせるスクリプト行が短い箇所が多い

逆に実装の難しい箇所は以下のようなものです。

・レース
・XR/AR
・３Dアクション

難しい箇所の原因としては以下の理由が挙げられます。

・画像をキャプチャして検知するという手段のため3Dでの状況取得が困難
・アニメーションをするため状況取得が困難
・操作がシビアなためタイミングの合った操作が困難

Airtestにはこのような特徴があるため、導入を考えている場合は、テスト対象のジャンルに気を付けて、実装するかを判断すると良いでしょう。

4.まとめ

パイロットプロジェクトにおいても、自動ゲームテストは、何もない状態から始めると数多の失敗の先に成功がある活動になります。そのため、粘り強い活動が必要です。ゲームテストでの自動操作はweb系のソフトウェアテストの自動化より複雑なUIが多いため実装も難しく、比較して自動テストの保守・運用コストが増加しやすい傾向にあるため、より効果が少なく感じられると思います。そのため途中で断念し失敗してしまうケースが多いことが、普及しない理由かもしれません。

自動ゲームテストはあくまでも開発プロセス全体で品質を向上させる手段の一つであるため、とりあえず導入することで工数が削減されるような銀の弾丸ではありません。テスト計画・テスト分析・テスト設計・テスト実行といった改善活動が未着手の場合は、それらの改善も同時に進めた方が、失敗しにくい品質向上の活動に繋がるでしょう。