JaSST21Hokkaidoに参加しました

これはFINAL FANTASYのようなメジャータイトルは特に、世界的な日本のゲームの広がりと日本市場の縮小などの要因から、全世界をターゲットに開発が進められることも多く、結果として字幕や各言語（リップシンク含む）のテストや人種や倫理観など世界中の様々なところにひっかからないか、のテストなども行っていて、量が膨大になっているそうです。

一方ゲームのプログラム部分はゲームエンジンやミドルウェアなどに任せられる部分が多いので少なくなっている、とのこと。

そのため、よく「単体テストをちゃんとやってシステムテストは少なく」といった、テストピラミッド的な考え方もありますが、ゲームにおいてはコンテンツの割合が大きいため、単体テストでは見つからない不具合も多く、「がっちゃんこしてみないとわからない」バグが多いそうです。

そこで、人手でのテストの限界がきており、自動化は必須になっているそうです。

太田さんがFINAL FANTASY VII REMAKE INTERGRADEで関わった自動テストツールの機能は

自動リプレイ
自動探索
バグ自動分類

だそうです。

自動リプレイは、人間がゲームをプレイしたときの動作を記録して、それを再生する機能です。

ただ、Webの自動化でもそうですが、ただ記録した通りに再生するのではテストがうまく動かない可能性が高く、特にゲームというのは不確定要素が沢山存在するものなので、その点の対応を色々工夫されているそうです。

たとえば、プレイヤーが敵と戦闘になった場合。

敵の動きというのは毎回異なるので（全く同じだとゲームとして魅力がない）、単にプレイヤーの操作を記録しただけでは、敵を倒せません。そのため、戦闘に入った時点で戦闘用のプログラムに切り替え、敵を倒したら再度自動リプレイモードに戻ってくる、という工夫をしているそうです。

細かい点では、戦闘が終わる位置、というのも毎回異なるので、人間がプレイを記録したポイントにキャラクターの位置を戻してそこからリプレイを再開する、といった工夫も入れているとのことでした。

次に自動探索について。

コリジョンと言われるような、特定の場所にぶつかるとキャラクターが3Dの物体の間を抜けて空間に落ちていってしまうようなバグを見つけるため、キャラクターにゲーム世界の部屋や特定の範囲をくまなく自動で歩き回らせるような仕組みを用意していて、これを自動探索と呼んでいるそうです。前述の自動リプレイと組み合わせて使っているそうです。

最後にバグの自動分類ですが、自動リプレイや自動探索の過程でバグが見つかったときにバグ管理システムに自動で登録されるようにしているそうですが、そうなると登録されるバグの量も膨大で、かつ本当にバグなのかどうかや、あるバグと他のバグが実は同件かどうかなど、人間が確認しようと思うとこれも手間がかかってしまうので、それを自動で分類する仕組みのことです。

というような、FINAL FANTASY VII REMAKE INTERGRADEにおける自動テストでやっていること、を主に紹介するセッションでした。

私がここまで書いた内容はほんとうにざっくりで、実際の講演ではかなりハイレベルなところまで発表されていました。このあとにナイトメアセッションが控えていたものの、「既にハードモード突入しているな？」という空気感。（楽しかったです）

全体通じて、今回はゲームの話ではあったものの、他の分野での自動化にも応用できる（気になれる）お話が多かったです。

一方「なるほどここを真似しよう」と自分がなれるレベルの話ではなく、最終的に「あっ・・・勉強しよ」という感覚が残りました。

基調講演の感想が「勉強しよ・・・」で終わってしまいそう（）
— 伊藤由貴 (Yoshiki Ito) (@yoshikiito) July 9, 2021

聴講時メモ（の抜粋）

一部リメイクの画像があるが、INTERGRADEのデモもちゃんとあるよ
太田さん担当と経歴
- 今は自動テストでビルドしてテストして結果を集めて、的なバックエンドが担当
- 品質管理部門からの依頼をうけてツールの調査をしたり
- 鷲崎先生と研究室同期
- IBM入って開発
- 2年くらいDeNAにいて
- SHIFTでシステムテスト自動化をして
- いまはスクエニ
- 家庭用ゲームの経歴は実は短いので、そんなにすごくないですよ
個人ネタスライド
- 好きなもの
  - 言語はPython, GroovyとかREPLで軽量なもの
  - ソフトウェアパターン：パイプ＆フィルター
  - 設計技術：DOA＋Stateless
  - テストvsデバッグ：デバッグ
- ゲーム
  - 太田さんはプレステを持ってない（！）
  - Switch RPGセールで買う。大体半額セールで買う。
  - 自社タイトルを遊ぶと気になって仕事をしてしまう
  - ゴエモンがすき
  - ライブアライブが好き
  - ゼルダとか
- 朝自転車のって運動している
- 太田さんのKindleライブラリ熱い
- MANNINGで本読んでる
- Packtもオライリーも
- ゲームは実は３番めで、技術書と自転車がトップの趣味
- 女性の生活系雑誌（オレンジページとか）はコミュニケーション等のためによく読んでる
家庭用ゲーム市場
- 太田さん個人の見解
- 少子高齢化してて
- 競合する娯楽もたくさんある
- 途上国の経済力があがって
- JRPG、という概念が欧米でも理解が進んできている
- つまり海外市場が大きくなってきている
家庭用ゲームのテスト
- コンテンツがリッチ化して、人海戦術が無理になっている
- 自動化する
- 全世界がターゲットになって追加されたもの、字幕やら言語やら（リップシンク含め）も徹底的にテストするし
- 倫理的なところ、多様性でひっかからないかなど丁寧に見なければいけない
  - FF7ではどのくらいLGBTQが出てくるかなどの比率も重視されているか、もテストした
- 多様性、人種だけでなくて「色覚多様性」あたりも工数かなりかけている
ゲームの開発プロセスと人員構成
- ゲームってプログラマーは増えない
- デザイナーがすごく細かくわかれている
- プログラマーの仕事はゲームエンジンをそのゲーム向けに特化させるとかそのへん
- プリプロダクション
  - ゲームとして成り立つものなのか、売れるものなのか、を評価する
  - 社長含めた幹部にチェックしてもらう
  - これができないとα以降にすすめない
- αは国内でなんとか
- βになると国外も
- マスターになると徹底的にバグだし、テストする
ソフトウェアとしての特殊性
- ここも太田さんの関わった家庭用ゲームから判断
- プログラムとコンテンツ（アセットと呼ぶ）の比としては、コンテンツが97%くらいだと思う
- 量産するのはコンテンツ
バグの特性
- コンテンツ間の結合
- 正直がっちゃんこしてみないとわからない、プログラマーレベルで単体テストしてもわからないことが多い。やってはいるんだけど。
- プログラミングのバグになると、デッドロックとかメモリ破壊とかそういうやつ
- どうしても繰り返しテストとか負荷テストとかそういうものが主になる
自動テストの対象
- 基本、機能と性能
  - ほんとはたくさんあるんだけど、人のテストエンジニア、ゲームテストのプロじゃないとダメってものがかなり多い
開発目的
- 機械が得意なテスト≒手動では苦痛が伴うテスト
  - レアなバグを発見するために同じ操作を繰り返す、とか
    - 太田さんも辛い
    - ゲームが好きなテストエンジニアでもつらい
- 手動テストの効果の最大化、を狙う
  - 集中する範囲を絞ったり
  - 手動テストを、ツールの補助で楽にしたり
本自動テストツールの機能と対象
- 自動リプレイ
- 自動探索
- バグ自動分類
自動リプレイのタイプ
- ゲームでないものだと、ランダム性をなくすことを目指していた。いろいろ固定して。
- ゲームの場合はランダム性がないとダメなので、ランダム性を許容したうえでどうするかをがんばる
自動リプレイのデモ
- バトル中のコントローラー操作はそのまま再生するのではなく、バトルボットというものに操作を切り替える
- バトルが終わったらまたリプレイに戻して、続きをおこなう
- バトルが終わった時点だとキャラの位置がかわっているので、記録時の位置まで戻したうえで再開するような仕組みになっている
- 状況によって、とくにボス戦によっては特殊な処理を入れたり
自動リプレイコア機能
- UnrealEngine向けの自動テストSDK的なものと、ゲーム固有のボットとを組み合わせてやってる
自動サーバー
自動テストサーバー
- ゲームの状態をスタックとして管理
同期メカニズム
- 記録時と再生時でスタックが異なる場合がある
  - カットシーンが先に来たり？とか
ゲーム固有コード
- 各種Botでがんばる
- ゲーム側から「こういう状態になったよ」というのを受け取ったら固有のBOTを動かして、おわったら戻す
サーバー上でのパス探索
- 記録時と再生時の位置などが違うとき
- SLAMというアルゴリズムの簡易版、ととらえてよい
ゲーム間で共有するコード
- ゲーム固有ボット以外
- あたらしくゲームの自動テストしようと思ったときは基本はゲーム固有コードを追加すればよい
  - 完全にそれだけですまない場合ももちろんあるけど
自動リプレイの評価
- レアバグ発見
- FF7のときには8章分くらいしかできてなかった
- INTERGRADEの前に18章分をREMAKEで作って、そのあとユフィ編を作った
- テスト対象が記録時の経路に限定されるのが課題
自動探索の例
- リプレイ以外は「事前に記録した経路に戻る」くらいしかしない
- これだとコリジョンとか見つけられない
- これを徹底的に見るために自動探索をする
リプレイと探索の組み合わせ
- リプレイは一本道的に進むが、探索を組み合わせると通る部分が増やせる
  - し、これを可視化するようなWebインタフェースも出してる
バグ自動分類
- 特にINTERGRADEで問題になったのが、あがってくるバグを分析するのが大変なこと
  - ほんとうにバグなのか
  - 偽陰性も偽陽性も両方あった
- ツールによってしか出ないバグ、とかはあっちゃだめなんですよね
- 同じバグが複数箇所で出た場合はまとめてほしい
バグ自動分類の目標
- 分析時間を削減しないとしんでしまう＞＜
- 欠陥分類だけでなく、原因にたどり着くまでを速くしたい
アーキテクチャ
- 手動修正、バグかもしれない的なものを設けているので、調べて本当にバグでした、的な登録
- GAFAMクラスの人でないと作れないレベル（太田さんもコード理解するのに2年くらいかかった、機能追加は今の太田さんでもできない）
自動テスト・ワークフロー
バックエンド改善V2.0
- プール化によって、どの開発機でもテストができるようにした
バックエンド改善V2.5
- ビルドやパッケージインストールのところを効率化して、実行時間を減らしつつ任意のテストを実行できるようにした
フロントエンド改善
- Jenkinsで動かした結果メール通知とかで飛ばす
- ゲームチーム側に気軽に使ってもらう必要がある
- 手動のテストエンジニアが自動テスト流して帰って、翌朝見る的な運用も想定
無限リプレイとデバッグ補助
カットシーンの制御と切り出し
- カットシーンが始まる前にキャラクターが居る位置が不定なので、想定外の動きをして変なことになる場合がある
  - こんな位置にはいないだろう、というところにいたり
自動テストビルド取得
- UIなどを従来はコマンドラインでコピーしてくる必要があった
- ランチャーでボタンを押すと、自動テストを組み込んだビルドが自動でダウンロードされる的な形にした
今後の開発
- PythonサーバのGILによるFPS低下解消
- 通信の際にシリアライズが問題
- バグの自動分類の精度向上
- 実行テスト決定エンジン
  - Jenkins上で、実行するテストをスタティックに決めていた
  - ルールエンジン等で重み付けをして、どのテストをどのタイミングでやるかを決定するような仕組みを考えたい
Q&A
- 同期メカニズムのあたりを詳しく
  - ゲームのアーキテクチャと実装コードが完全にわからないと同期のところは無理
  - FFのプログラム設計が非常にきれいにできていて、テストしやすかった
- 太田さん側からプロダクトコードに対して「テストしやすいようにこうしてほしい」とリクエストすることはある？
  - ７のときには入ったフェーズ的に余裕がなかった、ので優秀なエンジニアに頼んだ
  - いまサポートしているチームだとそういったやりとりも少しある
    - 一部開発を外部に委託していることが影響
    - テスト容易性のために何かをする、というのは自動テストの人側からするとあるけど、ゲーム作ってる側からするとそれで処理が遅くなるとかは絶対に避けたい。面白くなくなるとそれはもうバグである。
    - FFのナンバリングタイトルなんかはCPUとGPUを常に90％使ってるような状態
      - 自動テスト側もカリカリに速くしないといけない
  - コア部分はソフトウェアエンジニアリングもだけどコンピュータサイエンス力。GAFAMの人たち何がすごいかって、ソフトウェア・エンジニアリングじゃなくてコンピュータサイエンス側にあった。競技プログラミングのトップ層レベル
- 探索のところ
  - 毎回探索入れると大変
  - 一個一個入れていくのが大変すぎる
  - カットシーンやイベントが終わったタイミングで探索モードが入るようなフラグを設定している
- バグ自動分類もう少し詳しく
  - GUIのツール上で色々やれるようにしてる

S3C) ナイトメアセッション「太田さんが語る！テクニカルトークススーパーハードモード」

他ではあまり見ない

総じてマニアックな話になる＆座談会的な進行になることが想定されますので、事前に覚悟完了ください

が面白そうだと思って選びました。

午前中のQ&Aのときの流れも含めて期待しつつ、会議があったので頭15分くらい遅れて参加しました。

本セッションはSNSがNG、と書いてあったので感想及び聴講メモはブログにも載せないでおきます。

S5A) 実行委員セッション「テストの現状調査～世界を覗いてみよう～」

JaSST東京で以前辰巳さんがやってたセッションぽい内容かな？と期待して参加。

聴講メモ（抜粋）

State of Testing の話
回答してる層はテストエンジニアやQAエンジニアあたりの層が多い
- テスターとテストエンジニアとの使い分けみたいなのは特に厳密には決められていなさそう
回答者層はUSA/カナダ、西ヨーロッパ、アジア・中東（インド以外）が多い
テストチームの課題、わりと日本での実感と乖離がない感じ
アジャイルはもはや当たり前
- キャズム超えてる感じ
機能テストやCIはほとんど自動化されてる
リアルタイムアンケート
- テストの学び方、は「まずやってみる」「テストの書籍」
テスト技法や方法論
- 探索的やスクリプトベースが多い
- 増えてるところとしては、ユーザーシミュレーションやペアテスト
テストツール
- BTS
- アジャイルワークフローツール
- Office系
- SCM
- の順で多い
- Office系も5割くらいが使っている
テスト管理ツール
- テスト／QA管理ツールが4割くらい、他は2割弱くらいがマインドマップやプロジェクト管理ツールなど
他にテストしている人
- プログラマーやOpsが3割強
年収はどれくらい？
- USAあたりだと10年選手で1000万超えるデータもある
- 中国でもたくさんもらっている人がいるし、日本でも一部居る
- あげていきたいですね

「ライトニングトークス！～好奇心を刺激する午後のひととき～」

仕事対応のためおひとりめを聞き逃しましたすみません。

How to Session-Based Test

ネモさん

Rapid software testingより紹介
SBTとは
- 2000年にJamesとJonathan Bachによって考案
- 探索的テストのよりフォーマルな形
- セッションという単位で探索
チャーター
- テストセッションのための１～３文のミッション
- やる人にバリエーションの機械を与えるようなデザインにするもの
タイムボックス
レビュー可能な結果
- 通常はセッションシートの形で、様々な情報を含む
デブリーフィング

あんまり自分がやってない方面なので楽しく聞けました。

テストデータのやりくりいかがされてますか？

長友優治さん（クラスメソッド）

急にテストデータ必要になることってないですか
スクリプトでテストデータ作れるといいよ
- 急に必要になっても大丈夫になるし
- けっこう楽しいし
- コードがあるとエンジニアとの間で対話が生まれやすい

自動化エンジニアとしてこういう用途も普及していきたいと感じたセッション。

チームの会話から始める機能開発

川畑ひとみさん（サイボウズ）

Kintoneチームの開発者
スクラム開発
チームの会話とは
- 新規機能の実装や試験設計の着手前に関係者で議論する時間がある
- 参加者
  - プログラマー
  - QA
  - デザイナー
  - ライター
- 議論
  - 実装方針
  - 懸念点
- たとえばこんなコメントがでる
  - こんなときの挙動どうなるの？
- やること
  - コメントを分類して結論と一緒にまとめる
    - 仕様、実装方針、実装の進め方、動作確認・試験　など
- よいところ
  - プログラマー／QA共通間でリスクの共有などができる
  - プログラマーからは、QAに説明することで認識あわせが役に立つ
  - QAは実装上の懸念を把握して試験設計に反映できる

共有することとそこから気付けることって大事ですよねー。 QAと開発が対立、とかここの世界ではなさそう。

”そのまま教える病”から抜け出そう！

岡内佑樹さん（feat）

そのまま教える病から抜け出そう！ from Yuki Okauchi

エデュケーションファシリテーターという職種
「話長いですね」とよく言われてしまう
聴講者に質問：教育をする立場になって苦労していませんか？
- 教え方に問題があるかもしれません
仕様書やマニュアルから教えようとすると病気にかかってしまいます
- ドキュメント通りにそのまま教える病
  - ボキャ貧になる
  - 自分がこれで理解できたから相手もできるはずだ、的発想になってしまう
病気にかからないようにたとえ話を用いましょう
たとえ話はスベることも多い。だから
- 相手を知る、相手が知っていることでたとえ話をする
- 構造を理解して、知識の幅を増やす

自分これなってるなーと思うので、抜け出せるようにがんばります。

ゆもつよメソッドの扉を叩いたその先で

かとあずさん

QA初心者、勉強会初心者、北海道応援
JaSST東北でワークに参加した
2020年は各地のJaSSTに7回参加した
- 参加のたびに武器をゲットしている
持ち帰ってみると・・・
- 使い所がわからなかったり
- 変革にいたらなかったり
なぜだ？
- 視聴者感覚
- 課題が不明確
- 参加がゴール
- と考えた
課題を明らかにしよう
- 成果物がしっくりこない
- システム理解に時間がかかる
ゆもつよメソッドで
- 納得感のある、組織の資産が作れることがわかった
JaSST東北のあとで行動を起こした
- 社内のQAで共有
- プロジェクトに適用
なんかすごかったなー、だけで終わってしまいそうな方はいませんか？
- みんなでその先の道にいこう！
まとめ
- 勉強会には課題を持って参加しよう
- 参加後はアウトプットが大事
- 北海道は本当に良いところ

JaSST Tohoku実行委員としては感動のセッションでした・・・参加して得たものを普段のお仕事で活かしていただけるというのは幸せなことです。

まつさんのセッション

SNS等禁止だったので内容は書けませんが、普段自分がやらないことだったので非常に面白かったですー。

S6) 招待講演「医療現場でのテスト～IT化が進んでいる医療分野と、進んでいない分野～」

仕事と育児の都合で聴講できず・・・他の方の感想に期待します。

オープニング

基調講演 「“FINAL FANTASY VII REMAKE INTERGRADE"における自動リプレイ、自動探索、自動バグ分類の理論と実践」