2022年8月23日（火）から25日（木）の3日間にわたり開催となった、“CEDEC 2022”（コンピューターエンターテインメントデベロッパーズカンファレンス2022）。こちらの記事では、その2日目に行なわれたセッション“開発もQAも自動テスト！「LOST JUDGMENT：裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム（仮）」の取り組みについて”の内容をお届けしていく。
本セッションの講演者はセガの阪上直樹氏（第1事業部 QAエンジニア）、門脇健造氏（プロジェクト業務部 品質管理）、粉川貴至氏（開発技術部 ビルドエンジニア）の3名だ。
PS5『LOST JUDGMENT（ロストジャッジメント）：裁かれざる記憶』（Amazon.co.jp） PS4『LOST JUDGMENT（ロストジャッジメント）：裁かれざる記憶』（Amazon.co.jp）
ゲーム開発の現場において、開発スピートや品質の維持のための“テスト自動化”の重要性は日々高まっている。今回の講演では、開発部門とQA（品質保証・管理）部門により“テスト自動化チーム（仮）”を結成し貢献した事例について、『LOST JUDGMENT：裁かれざる記憶』での実例をもとに、開発とQAの両視点から紹介された。
時代が求めるニーズ。チームは数年前から胎動していた
本講演で扱うタイトルは、2021年に発売された『LOST JUDGMENT：裁かれざる記憶』。ジャンルはリーガルサスペンスアクションであり、とくにこのアクションという部分と、対応機種の多さ、対応言語の多さ、多拠点での開発体制といった部分が、本講演では重要になる。
また、昨年のCEDECの講演で紹介された“全自動バグ取りシステム”の機能、“どこでもリプレイシステム”が本講演の分野でも活躍したという。
デバック用のWindows版ゲームとツールを接続することで、手動でプレイしたデータをプログラミング言語“Python”のスクリプトとして出力し、リプレイデータを作成。あとはボタンを押すだけで、自動で特定のプレイを繰り返すルーチンが簡単に実現できる。
まずはテスト自動化を導入するきっかけから解説された。QA部門には以前からの悩みとして、マルチプラットフォーム化などによるテスト業務の増加、それに伴う必要な時間や費用の限度、想定外な後ろ倒しなどに圧迫されるスケジュール進行、リリース後にユーザーから不具合の報告が来ることへの複雑な心境などだ。
十分な時間が確保できれば、これらの悩みは解決できていたかも知れない。そこでテスト自動化が悩みの解決に有効なのではと考えたのが、QA部門におけるきっかけだった。
では、開発部門でのきっかけはどうだったのか。開発部門ではすでにテスト自動化に取り組んでおり、2020年発売の『龍が如く7 光と闇の行方』開発時点で“テスト自動化チーム（仮）”を結成していた。
この時点でのチーム構成メンバーは、開発部門と自動化技術者のみ。なぜ“（仮）”かというと、組織上認められたチームではなく、自動テスト普及後には解散する予定となっているためだ。
開発と自動化技術者だけでもある程度はチームは回せていたが、課題も浮上していた。本業である開発との時間の兼ね合いもあり、自動テストが作成できても保守、運用に限界がある。また、開発部門だけでは品質保証やテスト設計への知見不足も考えられた。
そこにQA部門からの自動化に関する提案があり、まさに渡りに船ということで、組織を越境したチーム結成に至ったという。
自動化技術者の視点からは、まずQA部門とは以前からテスト自動化についての取り組みはあったものの、直接的なアウトプットはまだ薄かった。開発部門に対しては、ここ数年間で直接プロジェクトに入り、テスト自動化に協力する場面が多かったという。
いざチーム結成。準備段階で立ちはだかる“環境の違い”
テスト自動化チームの結成にあたり、その準備は開発、QA、自動化技術者の3部門が、互いに協力して進めていったという。まずQAの事前準備としては、“環境”、“機材”、“人材”、“学習”が必要と判断された。
環境については、そもそも開発部門と同じ環境でテスト自動化が可能かどうかの確認が必要だった。これまで開発部門で完結していたテスト自動化が、物理的にも離れているQA部門でも同じように実現できるのかをすり合わせ、準備を依頼していった。
環境が整ったら、つぎに必要となったのは人材だ。テスト自動化メンバーには、新規スタッフを募集するのではなく、QAテスターのなかからプログラム知識に長けたメンバーを選出した。
つぎに機材。今回の環境では、テスト自動化の専用機材を確保する必要があった。同時にQAによる手動テストも行なう予定だったため、ひとつの機材をこれら別々の用途で共用すると、動作やデータの保存、プログラムの更新などの観点からトラブルが起きかねなかったためだ。
最後に、メンバーの学習について。自動化のためにはスクリプトの作成が当然必要で、まずはそのためのPythonの学習が必要だった。こちらは参考書による学習で補い、また『龍が如く7』で実際に稼働した自動化環境の試験運用による学習は大きく役立ったという。
続いて、開発部門で進めた準備についても解説された。まずはQA部門が進行する、学習についてのフィードバックだ。
さきのATM操作のような学習で作ったスクリプトなどに関して、月例でフィードバックを実施。何度かこなせば終了するものや操作が複雑すぎて自動化が難しいなど、手動テストのほうが早いものについては作成を止め、開発中のゲームである以上変更にも追随する必要がある点を共有。
また、デバック機能を自動テストで使用できる範囲についても、意識共有を行なった。
続いて、QA部門で動かすテスト自動化環境の準備に入る。『龍が如く』スタジオでの自動テスト環境は、バグやクラッシュレポートの自動報告機能と、ログ収集機能によるテスト結果の“見える”化機能をすでに内包していた。
こちらをそのままQA部門でも動かすシステムを構築していったわけだが、ここにいくつかの課題が生じた。
開発部門とQA部門はそもそも使用するパソコンなどの環境がかなり異なり、とくにサーバーへの通信速度の違いが重要だった。『LOST JUDGMENT：裁かれざる記憶』だとパッケージやダンプの容量は数十GBにもなるため、通信のやり取りが遅くなるのは避けたかったわけだ。
この通信速度の違いについては、重点的に検証と対策を講じていったという。そもそもこの環境でのエラー送信の仕組みは、フルダンプ（数十GB単位）をサーバーに自動アップロードするものとなっている。開発環境では自動テスト中に頻繁にエラーが発生するなかでも問題なく回っていたものの、QA環境では頻繁なアップデートはできないのではという懸念があった。
そこで対策として、エラー発生時にミニダンプ（数百MB単位）とフルダンプという、ふたつのダンプを出力するシステムを構築した。ミニダンプのみがサーバーに自動アップロードされ、フルダンプに関しては開発側でデータが必要となった場合などに手動アップロードする方式となった。
なお検証を進めたところ、QA環境からでもフルダンプのアップロードが問題なくできた。そのためこのミニダンプのシステムは、回線が細めな在宅環境からのエラー送信システムへと転用された。
こうして環境が整ったところで、続いては自動テスト運用のワークフローを検討していく。開発部門のみで行なっていたテストの運用ワークフローでは、エラー発生時には自動で“エラー送信”というチケットを、チケット管理システム（Redmine）にバグと区別して自動登録するようになっていた。
そのチケットをもとにダンプやログ、動画などから解析し、即修正するか“バグ”チケットに変更するかの判断を下すわけだが、このダンプやログの解析というのは開発者自身ではないと難しいと考えられた。
そこでQA部門用の運営ワークフローとして、エラー送信チケットの登録までは同じだが、解析フローを動画などの解析から、該当の自動テストと同じ条件で再現可能かを検証するものに変更。
再現できた場合はバグチケット化し、再現不可能だったが継続する場合は開発部門のテスト自動化メンバーに調査を依頼するようにした。
これらを踏まえ、チーム全体での自動テスト運用ワークフローが固まっていった。開発部門側のテスト自動化チームと、QA部門側のテスト自動化チームとがそれぞれ同部門への報告や情報共有を行ないつつ、部門の垣根を超えての報告や情報共有も随時行ない、フィードバックをより固めていく。
開発部門の準備で最後に行なったのは、“テストケース”の設計だ。一般的にテストで取り扱うテストケースは、ゲームのシナリオをクリアするなどといった“正常系”と、ランダム要素に関わる“異常系”がある。
『LOST JUDGMENT：裁かれざる記憶』はマルチプラットフォームかつ多言語対応であるため、正常系テストの組み合わせが爆発的に増える。異常系スクリプトの作成は難しくコツがいることも加味して、自動テストは正常系テストに注力し、異常系は手動テストチームに任せる方針を固めた。
こうしてQA部門と開発部門の準備は進み、自動化技術者のほうでもその準備に協力していった。学習面やワークフロー設計などのサポートのためにすり合わせを繰り返し、各所でフォローができたとのことだ。
いざ運用。コミュニケーションの円滑化も重要な課題に
いよいよチームの運用開始の準備が整い、自動テストのカバー範囲に関する計画を準備する段階に至る。ミニゲームを正確にクリアーする必要がある“ユースドラマ”を開発側が、それ以外のミニゲームについてはQAが担当するなど、適性を加味して割り振っていく。
いざ運用にあたり、QA部門ではまずテスト自動化を行なうスクリプトを開発部門と共同で作成。自動テストのサイクルも構築された。
サイクルのうち、3.の調査部分に関しては、テスト結果によっていくつかに分岐する。問題個所の手動での再現確認の結果、手動でも問題が発生した場合はゲーム側の不具合という結論になる。
再現できなかった場合は自動テストスクリプト側の不備となるので修正を行ない、前日まで動いていたものが動かなくなった場合などは、ゲームの仕様変更によるものか、変更が意図的なものかも含めて調査や開発部門への問い合わせを行なう。
この調査部分については講演内で、動画も合わせてさらに掘り下げられた。動画はゲーム内の“スティール”という調査アクションにおける、敵に見つからないように身を隠しながら目的地を目指す様子のものだった。
自動テストの実績は、毎日更新されるクリア結果ページに保存される。こちらで該当テストの成功回数がセロという結果が確認できた場合などに、手動による再現検証が行なわれる。
また、運用にあたりコミュニケーションについては、QA部門としては初の試みということもあり、拠点が離れていてもリアルタイムでの連絡や相談が可能、かつWeb会議などもできるツールとして、“Microsoft Teams”を活用。
コミュニケーションの実例として、動画を添付してのリアルタイムでの開発部門への相談例に加え、QA部門と開発部門のあいだにテスト自動化チーム（仮）が橋渡しの役割で入ったケースも紹介された。テストの自動化のみならず、定常の部門間のやり取りも円滑化し、プロジェクトの一体感向上に貢献できた。
続いて、開発部門での運用の模様についても解説された。開発部門では運用中、とくに“自動テストシステムの改善”、“マルチプラットフォーム×多言語対応”、“多拠点開発のサポート”に重きを置いたという。
マルチプラットフォームと多言語対応については、一部の組み合わせだけでも100を超えるパターンが生まれる。さらにそれぞれのパターンごとにメインシナリオやミニゲームなどが控えているという、膨大さへの対応が課題となった。
この問題には、条件別に組み合わせがずれていくように設定することで対応したという。全組み合わせのテストは不可能でも、プラットフォームや字幕・音声の言語の組み合わせ条件が他のパターンと似通っておらず、少しずつずれている組み合わせを試していくことで、制限内でも最大に近い組み合わせを網羅できるようになった。
多拠点開発のサポートについては、『龍が如く7 光と闇の行方 インターナショナル』開発時に問題点が洗い出されていた。
マルチプラットフォームかつ多言語対応だった『龍が如く7』では、テスト環境の日々のパッケージ更新でフランス語版だけ起動できないなどの問題が頻発。時差の問題などもあり、日をまたいでのテンポが悪いやり取りが非効率的だった。
その反省を活かし、『LOST JUDGMENT：裁かれざる記憶』では言語切り替えのみの自動テストを実施。確認時間と手戻りのロスを大幅に削減できた。
自動テストの精度も向上。結果的にはいいことづくめ
準備、運用を経て、実際にこのテスト自動化チーム（仮）はどのような結果を生み出せたのだろうか。まずはQA部門のほうから、結果についての報告がされた。
まずはよかった点として、夜間に自動テストを繰り返した最新の結果を業務開始と同時に得られることで、業務効率が格段に上がったことが挙げられた。
ほかに気づいたこととしては、後々の効率化のためには相応の準備時間が必要なことや、自動テストの利点を踏まえ、それぞれの特性が異なることなどが挙げられた。
手動では手が届かない部分などに自動化を割り当てることで人の手が空き、より手動で確認したい部分に人を割けるなど、特性を理解して割り振れれば大きなメリットが生まれる。
これらの経験を経てQA部門でできるようになったことは以下の通り。
- 開発部門と同じテスト環境を獲得し、なおかつPythonでのスクリプト作成などもできるようになった。
- 自動テストの結果内容を理解することで必要な行動を的確に選べるように。
- 自動化したいテストの内容もQA部門として考えられるようになった。
開発部門視点からの結果としては、まずは人員や環境の拡充も含めた、テスト自動化チーム（仮）の変化が挙げられた。そのチームによる自動テストの実績についても、前作にあたる『JUDGE EYES：死神の遺言』と比べ、自動テストによって検知できたエラー等の割合は倍近くまで向上した。
この割合については歴代タイトルと比べてみると、複雑なアクションゲームである『LOST JUDGMENT：裁かれざる記憶』でもRPGである『龍が如く7』と同水準の効率を達成した。
また、自動テストがカバーした範囲におけるクリアー率についてもほぼ100％を達成。言語対応も完遂し、また自動テスト自体の精度についても、前作『JUDGE EYES：死神の遺言』では不安定な部分があったのに対し、日々100％クリアを維持できたことから明らかな進歩が確認できた。
テスト自動化で得られたもの
講演の最後には、本事例の成果についてまとめられた。QAテスターのスキルアップによりカバー範囲が拡大した点や、最大級の課題だったマルチプラットフォーム・多言語に対して自動テストが非常に有効と実証できた点は、今後の新タイトル開発でも大いに役立つだろう。
今後の課題としては、まずはその有効性が確認できたこともあり、QA視点の自動テストの実施を今後より増やしていきたいとのこと。また、今回の事例では機材は開発側でのみ管理したが、機材不足は否めないため、今後はQA部門でも稼働数を増やしていければとのことだ。
また、『龍が如く』スタジオではテスト自動化について、ロードマップを設定している。自動テスト自体の進化、環境の進化、運用の進化の大きく3つに分けた目標について、今回の事例ではとくに運用の進化が大きく進んだと考えられている。
ただ、ここがゴールというわけではない。将来的には今回自動テストを作成できるようになったQAテスターのように、ゲームデザイナーやアーティスト、サウンドなどのスタッフにも、自動テストを作成できるようになってほしいという目標があるとのこと。
文字通りの“みんなで自動テスト”が実現した開発現場には、いったいどのような変化や進化が起こるのだろうか。テスト自動化の推進で時間の猶予が確保できるようになったとき、ゲームのクオリティーはどこまで向上するのだろうか。テスト自動化チーム（仮）の今後の活躍とその実績からは、目が離せなさそうだ。
