I.C.E. 人材育成セミナー『みなさん、ちゃんとテストしてますか？』（講師：遠崎寿義氏・伊藤大輝氏／ザ・ストリッパーズ株式会社）

I.C.E. クリエイティブ人材育成委員会では、加盟社がナレッジシェアをおこなうイベントのひとつとして、制作業務に必要な情報やテクニックを共有する「人材育成セミナー」を定期的に実施しています。その第4回目は開発における「テスト」がテーマ。『みなさん、ちゃんとテストしてますか？』と題し、2023年11月29日にオンライン開催されました。

登壇したのはザ・ストリッパーズ株式会社の遠崎寿義氏（代表取締役・クリエイティブディレクター）と伊藤大輝氏（テストディレクター）で、講義では同社が開発・運営を担当する人気スマホゲーム『逆転オセロニア』の事例等をあげながら、「テスト」についての考え方と実践について話していただきました。

I.C.E.の理事でもある遠崎氏が率いるザ・ストリッパーズは、ゲーム開発を中心にECサイトなどのオンラインサービスからアプリまでの幅広いデジタル領域で企画・制作や開発・運用をおこなっています。

いうまでもなくソフトウェアとハードウェアどちらの開発にもテストは欠かせないもので、「アルファ版」、「ベータ版」といったリリース前のテストから、リリース後のアップデートのテストや負荷テストまで、さまざまな形態のテストがあります。この講義では、企画・開発からリリース後のフェーズにおける「ソフトウェアの欠陥を発見し品質を高めるための一連の活動」という文脈にフォーカスしつつ、ゲーム以外でもさまざまな案件で応用できるノウハウが共有されました。
遠崎氏はまず、「テスト」を手動テスト（テスターによるデバッグ）、自動テスト（Unitテストなど）、品質管理（QC）・品質保証（QA）の3つのタイプに分類し、プロダクトの開発フローを例示しながら解説を進めます。

1. 企画・スケジュール
2. 仕様書・画面構成
3. デザイン
4. 実装
5. テスト（QA）
6. リリース

まず、このフローにおいて「テスト（QA）」の段階まで持ち込まれてしまっても対処できない問題があります。著作権や特許侵害の確認のような、仕様書・画面構成の段階で対処すべき法務的なことや、商標や画像・フォントなどの知財のライセンスやユーザビリティの確認といった、デザインの段階で潰しておくべき問題がそれで、これらの品質管理に関する作業も「欠陥を発見し品質を高めるための一連の活動」に含まれると遠崎氏は指摘します。また、テストの手前のソフトウェア開発、つまり実装の段階で自動テストをコードに組み込んだり、デバッグ用のAPIやツールを開発する必要もあり、こうした作業はまとまった「テスト期間」としてスケジュールに現れないため、その工数の見積もりが見落とされがちであると付け加えました。

次に説明されたのが自動テストで、その代表的なものがUnitテストです。Unitテストは、プログラマー自身がテストのために作成したコードを用いたテストで、クラスやメソッドといった最小のモジュールごとにテストコードが書かれ、ビルドやデプロイの際に自動実行されます。一般的なMVCモデルの開発ではModelとController、つまりView（UI）以外が対象となり、主にテスト用の入力に対して仕様どおりの値が戻ってくるかどうかをAssert関数などを使って検証するものです。とくに、複数のプログラマーで開発を進めている場合、それまで正しく動作していたソフトウェアにコードの改修や新機能の追加が干渉してバグが混入（エンバグ）するのを防ぐために有用なテストです。ほぼすべての開発環境にはUnitテストの仕組みが用意されており、Unityアプリである『逆転オセロニア』の場合はUnity Cloud Buildというビルドサービスに組み込まれたフレームワークを使ってテストを実行し、エラーがなかった場合にだけビルドが成功、エラーが発生した場合にはSlackに通知が行くようにしています。

遠崎氏は、UIを対象にシナリオテストをE2E（End to End）で自動実行するフレームワーク（Webアプリを自動実行するSeleniumやPlayWright、スマホゲームに特化したAirtestなど）も、あるにはあるものの、具体的なテストの実装とメンテナンスのコストが成果に釣り合うかどうかが悩ましく、開発初期のECサイトにおける膨大なユーザー入力の組み合わせを省力化するような、限定的な使い方であれば有用ではないかと述べます。

その他デバッグを助ける役立つツールとして、Google Firebase CrashlyticsやBacktraceなど、リリース後のソフトウェアで発生したエラーやクラッシュを自動的に検知・報告するようなバグ解析ツールも含まれます。DAUが数万を超える『逆転オセロニア』ではどうしても事前のテストでカバーしきれない環境のユーザーもいるため、バグ報告があった場合にユーザーIDと紐づけてスタックトレース（エラーの前に何が起きていたのかを追跡する情報）を辿りバグ修正に役立てることがあるといいます。それだけでなく、統計的にエラーやクラッシュの頻度の傾向が把握できるため、ザ・ストリッパーズではOSのアップデートなどで生じる不具合の対処にも活用しています。

ここで話題はいったんテストから、品質管理上必要な他の活動に移ります。先に述べた法務的な観点に加え、景品表示法、資金決済法、Google PlayやApp Storeのアプリガイドラインに沿っているかどうか、ソフトウェアのパフォーマンス、セキュリティ、専有容量の検証はもちろん、ゲームの場合はメモリハックやMODアプリへの対処などのチート対策も、いたちごっこではあるものの重要だと説明されました。

また、動作保証や瑕疵担保に関する動作環境は最初の開発受託契約で決められるべきだが、ザ・ストリッパーズでは動作保証端末以外の端末も幅広くテストするとのこと。保証外の端末で報告されたバグの対処はケースバイケースであるとも付け加えました。

そしていよいよ、手動テストの実際のフローの解説に入ります。

1. テストケースの作成
2. テストデータの設計・作成
3. テスト用デバッグツールの作成や準備
4. テストの実施
5. レポーティング
6. バグの修正
7. 修正の確認

手動テストの基本の流れはそれほど複雑なものではなく、必要なテスト項目をリスト化した「テストケース」というテストの段取りをまず作成し、テスターにその指示どおりにひたすら実行してもらいます。ただし、そもそも正常な動作が何なのかがわからなければ個々のテストが成功したかどうかの判断はできないため、前提として「仕様書がちゃんと作成されていること」が非常に大事であると遠崎氏は述べます。

このため、ザ・ストリッパーズではソフトウェアの仕様書をすべて、個別の機能ごとにGoogleスプレッドシートにまとめています。例えば、ゲームキャラの「スキル」が発動する条件の定義や、バトルのシーケンスを時系列で定義する「バトルフロー」などは文章でセルに記入され、正常な画面遷移がどうなるのかはFigmaなどで作成した視覚的なデザイン資料やスクリーン録画が、最終的にはテストケースと共にテスターに渡されます。

ここでプレゼンターは伊藤氏にバトンタッチし、テストケースの作成について掘り下げます。ザ・ストリッパーズでは、機能ごとにテスト項目が文章で列挙されたテストケースを、テストの進捗がひと目でわかるようにGoogleスプレッドシートに記載し、テスターがシートに検証結果を記入していく仕組みを取っています。

次にテストケースをどう作成するかですが、基本的には仕様書をもとに、必ずしも詳細に書かれていない、検証すべき動作の組み合わせパターンを洗い出していきます。理想はすべての組み合わせを考えることですが、実際にはコストや工数とのバランスの見極めが大事になってきます。次に語られたのがテストの「粒度」。ここでいう粒度とは、テストの範囲と詳細さで、機能の重要度や利用頻度によってそのバランスが変わってきます。例えば新規アプリの場合、クライアントサイドとデータの比重が大きく、バグがあらゆるところに潜んでいることを想定して詳細なテストケースを作成します。新機能の場合は、すでに安定しているクライアントサイドに追加された部分と、そこにアクセスする機能を重点的に検証します。また、『逆転オセロニア』ではアップデートでデータが追加されることが多いため、主にデータの検証を中心に行っています。こうしたデータの検証では、テストデータの作成をフォーマット化したり自動化することでテストケース作成の時間を削減し、その分検証作業に集中できるようにするのが望ましいといいます。

さらに、作成したテストケースを開発者や他の関係者がレビューすることの重要性も強調されました。とくに、テストチームから開発者にヒアリングシートを送り、検証時の注意点についてインプットを得たり、コミュニケーションをしっかり行うことが大切で、それによって影響範囲の見落としなどのミスを防げると伊藤氏は述べます。

テストの実施に先立ち、テスト用データ（マスターデータ）の設計・作成も必要になります。機能の正常な動作を確認するには、アプリにフィードするための正常なデータと異常なデータの両方を用意しておく必要があり、例えばECサイトの場合はそうしたデータを作成してCMSなどに登録しておき、テストに使用します。このとき、本番環境のデータをテストに転用するのは問題ないものの、逆にテストデータが本番環境のデータに混入することは絶対避けなければなりません。このマスターデータは、基本的にはデータベースに格納されているものをそのまま使いますが、『逆転オセロニア』の場合は、キャラの属性やパラメーターなどの数値の集まりがそれにあたり、データの変更だけでさまざまな動作をテストできるようになっています。Googleスプレッドシート上でデータを管理することでバージョン管理が容易に行なえるほか、Google Apps Script（GAS）を使ってテスト用のサーバーや別のシステムに送信して使えるようにしています。また、本番用のデータとテスト用のマスターデータはそれぞれGitHub上の別ブランチで管理し、サーバーごとに別のデータを適用できるようになっています。

そして、テストを効率よく進めるためのツールをアプリにあらかじめ組み込んだり、複数のテスト環境（クライアント・サーバーともに）を構築したりしておくことも重要です。ゲームなら、特定の時間で発生するイベントを検証するテスターがサーバー時間を変更できるAPIを用意しておいたり、あるいは検証作業のスピードアップのためにチュートリアルをスキップしたり、特定のレベルや状態からプレイを開始したりできるようなAPIを実装します。こうしたテスト用APIは設計段階で想定しておく必要があり、そのために開発工数の5〜10%を見積もっておくべきだと伊藤氏はいいます。

さらにこうした、テストを円滑に進めるためのツール群を扱うためのマニュアルを作成する工数もしっかり見積もるべきだと指摘する伊藤氏。これは特に外部の検証会社にテストを依頼する際に欠かせないものだと付け加えます。

テストケースにしたがっておこない、1項目ごとにテスト、レポーティング、修正、実装、修正確認のサイクルを繰り返します。伊藤氏は、このなかでもレポーティングが一番大事であると強調します。なぜなら、ただ起きたことが報告されても、それを安定して再現する条件と手順が示されていないかぎりバグを修正できないためです。そのために、テスト中にキャプチャ動画を取り続けることも重要だといいます。また、バグが見つからずに検証が終わった場合も漏れなく結果を記録してレポートする必要があります。

レポーティングにはRedmine、Jira、GitHub Issueなどのバグ追跡ツール（BTS）やプロジェクト管理ツールが使われますが、ザ・ストリッパーズではそれらのツールにおけるチケットの運用フローをGoogleスプレッドシートに文書化し、共有しているそうです。

また、バグレポートに関しても、「【ビルド番号】XXXにて、XXXを行うとXXXの表示が消える」のようなタイトルの命名規則を設けたり、本文にも検証時のビルド番号、「どの環境で」、「何を」、「どうしたときに」、「どうなったのか」といった重要な事項を必ず入れるようにフォーマット化しているとのことでした。

こうした検証によるバグの発見と修正が繰り返され、信頼度成長曲線上では報告バグ数に修正済みバグ数が接近していき、その差がゼロになることが理想です。『逆転オセロニア』の場合、テストケースを用いた検証はアップデートがリリースされるたびに差分を中心に実施されますが、その他にもフリーテストとして、ユーザーの視点でゲームを実際にプレイするゲーム大会を開発チームで定期的に開催しているそうです。また、アップデートの実装内容に関係なく基本機能を一通りテストするクリティカル検証、別の案件では特定のユーザーシナリオに基づく長期的なシナリオテストもおこなっていると話しました。

次に遠崎氏から体制についての説明がありました。テストケースの作成と基本機能の検証までを社内で行い、多端末検証やシナリオテストなど人手や端末の調達などの負荷が高い部分を検証会社に依頼するパターンのほか、プロジェクトの規模や会社の体力によって、テストケースの作成までは社内のテストディレクターが行うパターン、テストケースの作成も含めたテスト業務を全面的に検証会社に委託するパターンがあるとし、何社かの検証会社が紹介されました。

講義の最後には、時間またぎ処理（ECサイトのタイムセールなど特定の時刻をまたぐときの処理）、境界値やデフォルト値の仕様漏れ（以下、未満、以上、それより上など）、バージョンまたぎ（タイムイベントの実施とバージョンのリリースが重なる場合）など、想定から漏れがちなケースや後方互換性について、さらに通信切断時やボタンの連打・長押し、バックグラウンドからの復帰などのイレギュラー動作の検証について説明がありました。そうした動作のテストケースを作成するためには、テストディレクターが開発チームとコミュニケーションをとり、仕組みを理解しておくことが重要だと遠崎氏は強調し、セミナーは終了しました。

なかなか聴くことのできない講義内容が好評で、参加した方からは、「自社にはないノウハウを得ることができた」「大変貴重な機会だった」「すぐにでも実務に活かしていけそう」といった意見が聞かれ、密度の高い学びの場となったようです。
I.C.E. では、業界全体での人材教育にも力を入れています。イベントは定期的に開催しておりますので、ぜひご参加ください。
I.C.E. の活動に興味をお持ちの皆様も、お気軽にお問い合わせください。