【テクバン×MIXI×AIQVE ONE 3社共催セミナーレポート】テスト自動化でフリーテストを実現することはできるのか？（AIQVE ONE株式会社花房）

HOME

ブログ

イベント・セミナー

【テクバン×MIXI×AIQVE ONE 3社共催セミナーレポート】テスト自動化でフリーテストを実現することはできるのか？（AIQVE ONE株式会社　花房）

イベント・セミナー

公開日2022.11.04 最終更新日2024.08.07

【テクバン×MIXI×AIQVE ONE 3社共催セミナーレポート】テスト自動化でフリーテストを実現することはできるのか？（AIQVE ONE株式会社　花房）

#フリーテスト

当ブログを運営するAIQVE ONE株式会社は、テクバン株式会社、株式会社MIXIと共催し、「【テクバン×MIXI×AIQVE ONE】3社共催！テスト自動化事例LT会」を2022年6月28日に開催いたしました。
本セミナーは、テクバン株式会社品質ソリューション事業部が定期的に開催している、「ソフトウェアテスト」「テスト自動化」「アジャイル」「プロセス改善」など、「QA/品質保証」に関する様々なキーワードをテーマにしたイベントです。
今回のテーマは「テスト自動化事例のLT会」とし、実際に現場でテスト自動化に取り組まれている方々にご登壇いただきました。
この記事では、AIQVE ONE株式会社花房氏による「テスト自動化でフリーテストを実現することはできるのか」と題した講演内容をお届けいたします。

テスト自動化でフリーテストを実現することはできるのか？

私の方からは、フリーテストを自動化できるのかという疑問を検証した取り組みのお話をさせていただきます。

自己紹介

まず、簡単に自己紹介をさせていただきます。AIQVE ONEの花房と申します。AIQVE ONEでは、技術支援部にて、テストの技術面や取り組みの支援を行っております。

これまでは、ゲーム系と非ゲーム系の会社、半々ぐらいでキャリアを積んできました。昨年からこういった場でお話する機会が少しずつ増えてきて、昨年はCEDECで、今年はJaSST Tokyoでもお話しさせていただきました。

次に、簡単にAIQVE ONE株式会社の紹介をさせていただきます。
主にゲームに対してのソフトウェアテスト、品質保証を行っている会社です。人力のやり方にとらわれず、様々なツールを使い効率的にテストをしていくというスタンスで活動しております。

フリーテストの自動化？

では、本題の方に入っていきたいと思います。

テスト自動化の特徴

そもそも、テスト自動化には向いているものと向いてないものがあり、まとめると以下のようになります。

向いているものは変更が少ないテストや、実行頻度が多いテストです。
向いていないものは、その真逆の特徴を持つものです。では具体的にどういうテストかと考えたときに、アドホックテストや探索的テストなど、テストケースを使わないテストが該当するのかなと思っています。

ただ、ゲームに関して言うと結構自由度が高く、ユーザーの分だけ遊び方があるので、その機能テストを補う意味でのフリーテストというのが結構重要な立ち位置を占めているのではないかと思います。

フリーテストは一般的に、自動化には向かないと言われています。また、そのフリーテストの自動化に取り組んだ事例や活動の話を少なくとも私は聞いたことがありませんでした。それなら自分でやってみようと思い、周りのメンバーも巻き込んで、チームで取り組んだという経緯になります。

まず前提として、AIQVE ONEの自動化のツールはAirTestをベースとした、独自のツールを作って使っております。AirTestをベースにしているので、基本は画像認識ベースになります。こちらは、そのツールのUIになります。

ほぼ、AirTestと似通ったものになります。

フリーテストの分類

フリーテストの種類には、探索的テストやアドホックテスト、モンキーテストなどがあります

今回目標にしていたのは、アドホックテストを自動化できないかということです。ゲームのテストにおいて、いわゆるフリーテストと言ったときに、このアドホックテストの活動内容を指すことが多いので、まずはここをターゲットにしたいと思ったためです。

このアドホックテストは、人海戦術になりがちで、コストがかかる傾向があるため、アサインされるテスターの知識や経験によって効果が左右されるという面も結構あります。そこが機械に置き換えられればより効率的になるのではないかということは、考えて取り組みました。

モンキーテストの自動化

まずは段階的に取り組んでみようということで、モンキーテストの自動化を試してみました。仕組みは、このようになっています。

アプリを起動したあと端末の電池残量を見て、一定以下であればスリープを入れて充電するようにしました。その後、ランダムにタップするという処理を大体1000回単位で入れており、それが終わったら今度はスワイプを同じように入れています。その一連の流れが終わったら、アプリが起動しているかをチェックし、起動していなければアプリをもう1回起動するという処理を入れています。ですので、1回アプリを起動して処理を走らせてしまえば、あとはある程度自動で永続的に続くというかたちにはなりました。

実際にモンキーテストの自動化をしてみたところ、一応モンキーテストとしてのランダムな操作は成立していました。

画面をランダムに高速でタップしたときに、タイミングが絡むようなバグの検出には期待ができるのではないかと思っているのですが、やや動きがランダムすぎて、実際の人の動きとは程遠いかなとも感じました。また、スマホゲームなどでは、UI周りだけ回るという形になりやすく、ゲーム脱後のインゲームになかなか入らないことがありました。さらに、できればもう少し人の動きを模したような行動を取らせたいというのもあります。

ただ、機械なので長時間稼働が可能なため、ひたすら動かしてクリティカルなバグがないかを確認する場面では、一定の有効性はあるのではないかとも感じました。

アドホックテストの自動化

今度はモンキーテストからアドホックテストに進化させるにあたり、テストケースをベースとしてやっていくことにしました。テストケース1つにつき1つのスクリプトとし、テストケースの数だけスクリプトを作り、それを連結させて実行していくというやり方です。実行するときにもリストに沿って上から順にというかたちではなく、ランダムに実行していくという処理を実装できないかと考えました。

仕組みのところは、基本モンキーテストと同じようなかたちになっています。

違うところは、スクリプトを複数用意して、それをランダムに実行順序を決めて順番に流しているところです。

実際、アドホックテストを自動化してみてわかったことは、やはりモンキーテストよりは人の動きに近いのかなということです。テストケースをベースにしているので、ものすごく短いシナリオみたいな形になったのかなと思いました。ただ、やはり連打系などは検出しづらくなりました。そしてこれはモンキーテスト、アドホックテストどちらにも言えるのですが、現状、検知できるバグがアプリ落ちに限られるので、そこは課題だなと思っています。

またアドホックテストを行うときに、テスターであれば、その人の経験やテスト結果などいろいろな情報からバグに当たりを付けることができます。それがまだ機械では再現できていないので、それもどうにか取り組めないかなと考えております。

今後の取り組みとして今考えているのは、自動テストをどのくらい実行したのか、どのくらい異常がでたのか、などの結果の記録ができるようにしたいということです。そして、アプリ落ち以外の異常の検知ができないかというところにチャレンジしていきたいと思っています。また、異常が起きた時にメールやチャットツールに通知を飛ばすとか、自動でBTSにバグチケットを起票するということもやりたいと思っています。さらに、異常が起きたときの直前の行動を記録しておき、再現することを、AirTestをベースとした画像認識ベースのツールで実装できないかということも目論んでおります。

これで私の話は以上になります。
ご清聴ありがとうございました。

※この後行われた、テクバン株式会社の市川様、株式会社MIXIの村田様による登壇の模様は、後日アップいたします。