2021年1月28日、第2回目となるmonoAI tecnology（現:AIQVE ONE)主催のオンラインセミナー、QA Tech Nightを開催いたしました。この記事では、その中で行われた当社monoAI technology(現:AIQVE ONE)の第一QA部　技術支援セクションマネージャーの花房によるセッションの内容をお届けいたします。

＜関連記事＞
【QA Tech Night レポート】QA組織が最後の砦から脱却するために―株式会社アカツキ福岡　山﨑氏
【QA Tech Nightレポート】パネルディスカッション―「ゲーム業界におけるソフトウェアテストの理論の浸透と自動化」

はじめに

本日はゲームテストの現状とテストの自動化という内容で、お話をさせていただきます。
まずは自己紹介から。わたしはmonoAI technology(現:AIQVE ONE)の花房と申します。

第一QA部の技術支援セクションという部署で、テストに関する技術的な支援や社内教育を中心に活動しています。

これまでゲームパブリッシャーでゲームのテストだけでなく、第三者検証の会社に勤務してゲーム以外にもテストリーダーやテストマネージャーというかたちで広くテストに携わってきました。

ゲームテストで属人的なやり方の現場から、ソフトウェアテストの考え方が浸透している現場まで、幅広く経験しています。

本日は、第三者検証の視点という立ち位置でお話しさせていただきます。

パブリッシャーさんであれば、内製の品管がありそこでテストを実行することもあれば、パブリッシャーさんからデベロッパーさんに開発が流れて、デベロッパーさんの中ではテストまでまかなうのが難しいので、弊社のような第三者検証にテストの相談を受けることもよくあります。

そういった視点でお話をさせていただければと思っています。

ゲームテストの現状

まず、ゲームテストの現状についてお話しします。
ゲームの開発はリリース直前まで仕様が決まらない、変更が入り続けるということがよくあります。

その原因はいくつか考えられます。

たとえばパブリッシャーさんと権利元との調整がなかなかスムーズに進まなかったり、やることが多くてタスクが膨れてしまうと、プロジェクト管理が難航してしまいます。

また要件定義や設計に十分な時間がとれず、手戻りが多くなってしまうこともあるかと思います。他にはクローズドベータなどで、ユーザーの反応をみて仕様を大きく変えるということもよくあります。

ゲーム開発は基本的にウォーターフォール型開発が多いですが、実際にはきれいにウォーターフォールで進むことは少ないと考えています。

ウォーターフォール型で工程が進む中で枝分かれをし、また前工程の作業をすることも多いかと思います。

ゲーム開発はクリエイティブな活動なので、アイデアが突発的に湧いてきてぎりぎりまで調整を入れることも多く、そのため仕様の固まっている部分から進めていくことが多くなります。

その他、なかなか仕様が固まらない部分などもあり、上図でいうと、あとから進んできたものが緑の枠の部分ですが、設計をしている一方で要件定義をしていたり、テストの段階まで進んでいる一方で設計が終わっていなかったりといったこともあります。

大きなウォーターフォールの中で小さなウォーターフォールがいくつか進んでいくという風に、プロジェクト管理が複雑化することもあり得ます。

ぎりぎりまで調整が入ると、スケジュールがタイトになってくると思うのですが、リリーススケジュールの変更は難しかったり、不可能だったりするため、いわゆるデスマーチに陥ってしまい、関わるメンバーも疲弊していくのかなと感じています。

また、ドキュメント類の更新も追い付かなくなるかと思います。
結果、ドキュメントの更新が全くされなくなり、正しい仕様は直接の担当者しか分からなくなってくるという懸念も生じます。最終的には、「実装が正の挙動です」というところまで陥ることもあります。

そういった状態になると、テストをする立場の視点では、テストベースとなる情報が乏しくなり、正しい振る舞いが分からなくなってしまうのです。

振る舞いをベースとしたテストが行えず、一般的に「ここおかしいよね」といった視点での、バグ検出が目的のテストに特化するというところに繋がってしまいます。

「なんでこのバグを見つけられなかったの？」とあとから言われることもあるのですが、正しい振る舞いがわからなければ、その動きが正しいものかも分かりません。

先ほどのようなかたちになると、テスト自体も属人性の高いフリーテストを好むとか、そういった類のテストに特化するという傾向があります。

経験豊富な人が行えばきちんとバグを狙ったテストができるかと思いますが、経験の浅い人が自由にプレイするというやり方をしてもバグを見つけるのは難しいと思っています。結果、ユーザープレイの延長のようなかたちになると思うのです。

業界全体でも、「実際にゲームを動かして偶然バグがみつかる」という風にとらえられています。結果、ひたすら人海戦術で長い時間をかけるといった方法に頼る意識が強まっているのかなと考えています。

このような考えが強いので、テストの仕事自体に専門的な知識や技術が必要だという認識がされづらいところもあると感じています。

また、開発の方の心理として、「バグが出たら安心」という傾向があると感じています。またバグの内容についても、何かが止まってしまうような影響度の高いバグがでれば一番いいのですが、何も出ないより何か出た方がよいという心理もあるようです。
バグの報告が全くないと、開発の方は逆に不安になるようです。

そういった面もあり、バグを出せるテスターが業界的に重宝されますが、バグを出せる人、出せるようにする人を教育するためのナレッジ等の環境が整っていません。結果、個々のセンスやポテンシャルに強く依存する形になっているという現状があります。

実際、私が結構前にパブリッシャーにいたときには、1つのタイトルで200人弱かけて1年まるまるかけてテストをし、1タイトルで3億円程度かけていたということがありました。

その当時はまだソフトウェアテストという考え方が薄かった時代なので、人海戦術で人数をかけてテストをするという考え方が強かったのですが、そうした中でテストは誰でもできるという間違った認識がゲーム業界の中で蔓延してしまったのではないかと思います。

もちろんソフトウェアテスト意識が高いゲーム会社さんもいらっしゃいます。

傾向をみると、昔からコンシューマーゲームで頑張っている会社さんより、比較的最近スマホゲームから参入してきた会社さんの方が、ソフトウェアテストの意識が高い場合が多いようです

スマホゲームは、いち早くサービスをリリースし、ユーザーの意見を取り入れよりよくしていくことが重要なので、人海戦術で長い時間をかけるというやり方が、そもそも合わないのではないかと思います。

テスト自動化について

次にテスト自動化の話に移っていきたいと思います。
ゲーム業界のなかでもテスト自動化の話題は増えてきていると感じています。昨年も一昨年もCEDECのなかでいくつかセッションはあったかと思いますが、たとえばその講演の中で出てきた「FF（ファイナルファンタジー）」とか「龍が如く」などは、長い時間取り組みをしているものが少しずつ結果がでてきたということかと思います。

たとえば自動化の話を聞いて夢をみてぱっと取り組んでも、なかなか結果にはつながりにくいと感じています。

テスト自動化のアンチパターン

こちらはテスト自動化研究会によるシステムテスト自動化カンファレンスのアンケート結果になりますが、大小あわせて何かしら問題があるというところは9割ぐらいになっています。ばっちりうまくいっているというところはほぼ少ないです。

その中でも共通して失敗につながってしまうケースがあります。
1つ目はテスト自動化の目的が明確にされていないことです。きちんと目的を明確化しておかないと、自動化すること自体が目的化してしまいます。そうすると時間やコストをかけても、成果が上がらないということになってしまいます。

2つ目は、テストの内容自体が明確でない場合です。
そのテストケースで何をしたいかが明確でなかったり、テストをする人によってやることが違ったりしてもテスト自動化に向かないところがあるので、きちんとやることを明確にすることが重要です。

自動テストはどうしても決められたことしかできないため、テストの手順や結果の各判断などは明確にしておく必要があります。

3つ目としては、最初から大きな範囲で自動化するパターンです。自動化は段階を踏んでやっていくのが一般的かと思いますが、欲張って広い範囲で自動化を進めてしまうと、自動化すること自体が目的になってしまうんですね。

そうして、あまり使われないもの、あまり行われないテストに対して自動化を試み、そのためのスクリプトを作っても使われないということになって、もったいないかなというところがあるので、効果が出にくいかと思います。

テスト自動化の向き・不向き

次にテストの自動化の向き、不向きについて解説していきます。

これも一般的によくあるというかたちなのですが、不向きなものとしては、

・頻繁に変更が入ってしまうもの
・テストの頻度が低いもの
・バグ検出を目的としたもの
・テスト結果が明確に判定できないもの

です。

上記のようなものだと探索的テストやアドホックテスト、ユーザビリティテストなど、人の感性で判断するものが合うのかなと思っています。

向いているものとしてはその逆のものです。

・あまり変更が入らないもの
・テストの頻度が高いもの
・テスト手順が明確なもの
・テスト結果が明確なもの

リグレッションテストやクロスブラウザテストなど、変更がなくて同じテストを使い回しできるテストが向いているかと思います。

スマホのゲームはバージョンアップを繰り返し、運営も年単位で続いていくかと思います。運営が続いていけばゲームのボリューム、仕様が肥大化していって新しい部分のテストで手一杯になり、既存の部分の影響確認などは、なかなか手が回らなくこともあるかと思います。

そんなときにリグレッションテストを自動化することで、テスト工数を抑えながら既存機能の確認もできて品質の安定化にもつながるため、スマホゲームについては自動化の効果は高いと感じています。

ただ、先ほどもお話ししましたが、現状のテストは属人的なフリーテストに頼っていたり、テストケースと呼ばれているものより、チェックリストのような記述内容があいまいなものが使われることが多かったりとか、そもそもテストの計画やテスト戦略の意識が弱いというところが、傾向としてあるかなという印象です。

こういった現状の文化の中では、テスト自動化は成功しづらいのではないかと思います。

そこで必要になってくるのが、ソフトウェアテストという考え方になります。
テストを自動化するにあたって、テストの上流工程であるテスト計画・テスト戦略のところ自動化の方検討していくというのも大事だと考えています。

あとは、そもそもテストケースに関して、テスト手順や期待結果を明確にしておくことで、そのあとのテスト自動化につなげやすくなると感じています。

ソフトウェアテストの重要性

また、ソフトウェアテストの考え方が重要だと考えています。

こちらはよくあるテストプロセスになるんですけれども、現状のゲームテストの中で、こういったテスト計画から始めていくようなプロジェクトとかテストのやり方はそこまで多くないと感じています。

まず、テスト計画は非常に重要だと考えています。テストの工程の中では上流の工程になるのですが、テストの目的や範囲、リスク、スケジュールなど、テストをするにあたって考えなくてはならないものをすべて洗い出すためです。そのなかでテストのアプローチ方法として自動化もあると思うのですが、方針としてどこを自動化していくかというのをここで定めていくと、そのあとの自動化にスムーズに移行できると考えています。

次にくるのが、テスト設計と呼ばれる工程です。テスト分析・テスト設計・テスト実装と呼ばれる工程になるのですが、テスト対象の機能の洗い出しやテスト観点の洗い出し、前提条件や実施パターンといったところを網羅して、テストの目的を明確化していきます。

この工程で、何をテストにするのか、どういう風にテストするのかをきちんと定めておくことで、テスターに依存せず、テストするたびに同じテスト内容になるという形ですね。

やることを明確にするというなかで、テスト技法が活用できます。経験値や感覚に頼るというより、テストの技法をうまく活用しながらやっていくと結果的に効率よく抜け漏れの防止や重複パターンの削除ににつながり、効率的なテストに繋がっていきます。

テスト技法は手動でやるのもありますが、ツールも出ています。2020年の秋ぐらいに、ベリサーブさんからリリースされたGIHOZというツールは、私も活用しているのですが、なかなか便利です。
たとえばペアワイズテストですと、いろいろな組み合わせの中から最適なパラメータのペアの組み合わせを自動的に抽出してくれます。全てを網羅すると100個あるのが、ペアワイズ法でテストすると20個の組み合わせになるとか、そういったことをやっていくと論理的で効率的なテストになってくるかと思います。

monoAI technology(現:AIQVE ONE)の取り組み

それでは、弊社がどういう風に取り組んでいくのかというところをお話しさせていただきたいと思います。

テスト計画を必ず立てる

1つ目は、弊社ではテスト計画を必ず立てるようにしています。ゲームのテストでいうと上図の赤の矢印のところから、いきなりチェックリストを作るようなやり方が比較的多いと感じているのですが、そうするとテストの方向性・スコープといったものを定めず進めていくことになるので、やってほしいこととやることの認識の齟齬が発生してトラブルになりやすいのかなと感じています。

弊社ではしっかりそこを定めるためにテスト計画を必ず立てるようにしていて、認識の齟齬の防止に努めています。

テスト設計を行う

2つ目としては、テスト設計をきちんと行っております。

仕様書に書かれているものをコピペに近いようなでチェックリスト化するというのがよくあるやり方ですが、そうすると必要な機能の洗い出しや必要な観点、やらなければならないテストの抜け漏れ、あとはパターンを網羅できないということにもつながります。

弊社では機能と観点の洗い出しをしています。それを中間的な成果物としてテスト設計書という形でまとめてレビューすることで、テストケースを何千と作る前にテストの内容の確認ができるので、手戻り工数の削減につながったりとか、テスト内容の妥当性が効率よくできたりすることにつながっています。

探索的テストの活用

3つ目に、探索的テストを活用するようにしています。

なるべく属人的なやり方をおさえたいというところで、テストチャーターを活用して、それをセッションで区切ってやっていくという方法で取り組んでいます。

ある程度一定の範囲内で自由度をもってバグの探索をしていくということですね。
完全に人のセンスやポテンシャルに依存するわけではないので、完全なフリーテストよりは個人への依存度は減らせるというところに繋がっています。

2種類のテスト自動化アプローチの使い分け

最後に、自動化のアプローチの仕方です。
弊社ではいくつかツールを活用していて、その中の自動化のツールとして2種類あります。

プログラミングがいらないノンプログラミングのビジュアル的なスクリプトを組んでいく方法と、ごりごりプログラミングをしていく自動化の方法ですね。この2種類の方法を、適宜使い分けています。

プログラミングがいらないビジュアルスクリプトの方は、テスターの方でも自動化に取り組めるようになっているので、現場レベルで、作業で必要なところを自動化して繰り返しテストを行うということをやっています。

難易度の高いものをやろうとすると、やはりプログラミングが必要になってくるので、弊社の自動化エンジニアの方でごりごりプログラムを組んで、ビジュアルスクリプトとプログラミングの使い分けをしていくようにしています。

最後に

ソフトウェア開発の中で、テスト工数が占める割合は30％と言われています。

それだけコストもかかり、工程としても重要なところになってくるのですが、
ゲーム業界の単価的なところでいうと、開発エンジニアの場合はゲームでも非ゲームでもさほど変わりません。

ただ、テストになってくると、ゲーム・非ゲームでかなりの単価の差があると感じています。

テストの工程自体はゲームでも非ゲームでも重要なところは変わらないと思うのですが、これだけ大きな差があると、昔ながらのゲームデバッグの文化みたいなものが、ゲーム業界のテストの成長を阻んでいるのかなと思います。

先ほども少しお話ししましたけれど、ゲームのテストは誰でもできるという認識がいまだに根強く、それが単価にも表れているのではないかと感じています。

ソフトウェアテストの技術者は、専門的な知識や技術が必要な専門職であるという考えが、テストの自動化、ゲーム業界のテスト品質の向上につがっていくのではないかと思います。

これまではゲームデバッグと呼ばれるやり方が主流だったと思うのですが、ソフトウェアテストという考え方も広まってきていると思うので、こういったゲーム業界のテストに関する考え方や文化も変わりつつあると感じています。

本日は、ご清聴ありがとうございました。