「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム

CEDEC2020の講演資料です。
『「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム』

株式会社セガ 第1事業部 阪上直樹 / 株式会社セガ 開発技術部 粉川貴至

Transcript

1. 「龍が如くスタジオ」の QAエンジニアリング技術を結集した 全自動バグ取りシステム 株式会社セガ 阪上直樹 Ⅹ 粉川貴至
2. QA Build 自己紹介 株式会社セガ 第1事業部(龍が如くスタジオ) QAエンジニア 阪上 直樹 株式会社セガ 開発技術部 ビルドエンジニア 粉川 貴至
3. QA みなさんバグは好きですか？
4. QA 龍が如くスタジオのバグチケット数の推移 17,448 13,367 5,095 22,963 11,857 12,211 17,346 25,155 龍 維新 2014年 龍０ 2015年 龍極 2016年 龍６ 2016年 龍極２ 2017年 北斗が如く 2018年 JUDGE EYES 2018年 龍７ 2020年 ゲーム規模の拡大とともにバグチケット数も増加傾向
5. QA つらいですね… でも大丈夫！
6. QA 本講演が終わるころには バグをハグしたくなります！
7. QA バグ作業フローの自動化 本講演のテーマ
8. QA 修正確認 修正 選別 報告 探索 バグ作業フロー（手動の場合） チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート
9. QA • バグやタスクを一括管理するシステム – 龍が如くスタジオではRedmineを使用 • バグチケットのステータスの流れ チケット管理システムについて 確認待ち 対応中 新規 差し戻し 確認済 修正開始 修正完了 修正確認OK 修正確認NG チケット管理システムの詳細は『「龍が如く」の高速デバッグ術 ～そびえ立つバグの山を踏破するための弾丸ワークフロー～』 http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
10. QA • ゲームの開発効率を上げるために最重要 – バグの処理作業に時間がかかると最悪発売延期 – 自動化がデバッグ期間の短縮につながる – 単純なバグ取りに人的リソースをかけたくない なぜバグ作業フローの自動化するのか？ 全自動バグ取りシステムを作ろう！
11. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
12. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
13. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート テスト 環境構築
14. QA 【テスト環境構築の自動化】オートテスト 帰宅前に各PCで オートテストクライアントを実行 設定ファイル(Excel)から iniを生成 最新ビルドを取得 ゲームを自動起動 (iniファイルのシナリオ/条件) エラー通知
15. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト 環境構築 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート テスト実行 テスト作成
16. QA • どこでもリプレイシステム – 自動テスト作成・実行するためのシステム – 手動プレイをリプレイ用スクリプトとして記録・ 再生 – プログラミング知識なしで自動テストが作成可能 – リプレイ用スクリプトはPythonを採用 • 後から条件分岐や繰り返し処理を追加可能 • 将来的な画像認識や機械学習との連携を想定 【テスト作成・実行の自動化】
17. QA どこでもリプレイシステムのデモ 手動プレイを記録中 リプレイ再生中 手動プレイ中にどこでも記録・リプレイが可能！
18. QA 外部ツール ゲーム内 どこでもリプレイエディタ GUI(C#) WebSocket サーバ どこでもリプレイシステム（記録） ゲーム動作を アクション単位で スクリプト化 ゲームを手動で プレイ
19. QA 外部ツール ゲーム内 どこでもリプレイシステム（再生） アクションを指定 どこでもリプレイ CUI(Python) 結果通知 結 果 JSONで 受け渡し WebSocket サーバ アクション Pad情報 どこでもリプレイエディタ GUI(C#) 行 ご と の 結 果 p y フ ァ イ ル path(x,y,z)を アクション(JSON)に変換
20. QA アクションとゲームの入出力 アクション ゲームステート 疑似Pad情報のみ 手動プレイとほぼ同じ動作であることを保証 自動テストの詳細は『「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて』 https://www.slideshare.net/SEGADevTech/7-234572005
21. QA どこでもリプレイシステムのテスト範囲 シナリオクリア コリジョン抜け パフォーマンス 計測 アイテム コンプリート UIガチャ押し ミニゲーム リプレイ用スクリプト の組み合わせ プレイログの 機械学習 ランダム 正確 探索的 ユーザープレイに近いバグを検知（研究中） 新規バグ エンバグ (デグレ)
22. QA ランダムなテストの例 コリジョン抜け (酔拳のような動き) バトル用 ミニゲーム用 ポーズ メニュー用 ゲームの状況によって自動パッド操作を切り替え アドベンチャー用
23. QA 探索的テストの例（ログ活用） 手動・自動テストの リプレイスクリプト を登録 ログサーバ Elasticsearch 検索でマッチした リプレイスクリプト を実行 開始・終了座標、 シナリオ、ステージ等 でタグ付け
24. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート テスト 環境構築
25. Build • オートテストクライアントとJenkinsの使い分け – オートテストクライアント • 利用者（テスト協力者）が扱いやすい – 利用PCで実行状態がわかる – 起動前と終了後の処理を正しく行う • 開発の空き時間での運用 – Jenkinsからの実行 • オートテスト管理者が扱いやすい – より複雑なオートテスト制御を行う • 24時間稼働している前提での運用 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト 24時間稼働している前提での運用 開発の空き時間での運用 サブシナリオのテスト • 1つ30分～2時間程度のサ ブシナリオが50以上 • 全サブシナリオを効率的に 実行したい
26. Build • Jenkinsからより複雑なオートテスト制御を行う – 実行内容の制御 • テスト対象の指定 – セーブデータ、リプレイ用スクリプト • タイムアウト設定 – 実行PCの制御 • 1つ1つのサブシナリオテストを順に空きPCに 割り当てて実行していく 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト
27. Build • Jenkins実行でのジョブ実行例 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト Autotest_Master_Pipeline node: autotest-001 node: autotest-002 node: autotest-003 AutotestJob #111 sub01.py 空きPC(ノード)を検知して次のオートテストジョブを実行 AutotestJob #112 sub02.py AutotestJob #113 sub03.py AutotestJob #114 sub04.py 結果：成功 結果：失敗 結果：失敗(タイムアウト) Autotest_Master_Pipeline は1000周以上、AutotestJobは4万回弱実行
28. Build • おまけ：制御用パイプラインスクリプト概要 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト stage(テスト設定エクセルのロード) { // テスト設定エクセルには1ケース1行で実行用パラメータが記載されている // オートテスト用リポジトリからファイル一式を更新 // エクセル⇒csvに変換、読み込み } stage(テスト名) { while(!executed) { // 実行可能なノードの検索 def c = Jenkins.instance.computers.find { it.isOnline() } // 実際はラベル条件などもチェック def idleExecutors = c.executors.findAll { it.isIdle() } // パラメータを渡してオートテストジョブを実行 build job: 'AutotestJob', parameters: [string(name: 'AUTO_INPUT_FILE', value: auto_input_file), string(name: 'SAVE_DATA', value: save_data_file), (中略), [$class: 'LabelParameterValue', name: 'RUN_ON', label: c.getDisplayName()]], propagate: false, wait: false // 実行できるまでスリープしながらループ sleep 30 } } // 1周終わったら次のジョブを呼び出す build job: 'Autotest_Master_Pipeline', propagate: false, wait: false
29. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート バグを発見
30. QA 【エラー検知の自動化】 • エラー検知の種類 – 例外（アプリケーションエラー） – ASSERT • 例外と同じくエラー扱い – WARNING • 開発モードは継続可能 • テストではエラー扱い – テスト結果分析 • どこでもログ分析で進行不能等を見える化 適切なアサーションを大量に入れる どこでもログ分析の詳細は 『無料で始める！ 「龍が如く」を面白くするための 高速デバッグログ分析と自動化』 http://jasst.jp/symposium/jasst18tokyo/pdf/D4.pdf ©SEGA
31. QA オートテストのエラー検出数と割合 オートテスト 8,102件 18.6% 龍が如く6 命の詩。 (ランダム＋パス) 龍が如く7 光と闇の行方 (ランダム＋Python) オートテスト 手動テスト JUDGE EYES：死神の遺言 (ランダム＋Lua) オートテスト 16,930件 33.4% ※2020年7月に集計 オートテスト 29,242件 68.5%
32. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 自動化 自動化 自動化 自動化
33. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
34. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート バグの周辺 情報を収集
35. QA 龍が如くスタジオのクラッシュレポート機能 【バグ周辺情報収集の自動化】エラー送信 ゲーム実行中に 例外発生！ ネットワークドライブ • ダンプ • ログ • スタックトレース • スクリーンショット • 直前の動画 • リプレイデータ メール送信 • ダンプ表示batのURL • スタックトレース • リビジョン チケット管理システム (Redmine) ログサーバ 1エラー数百MB～数GB
36. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート バグチケット 作成
37. QA 【チケット作成の自動化】どこでもバグ報告 バグ報告に必要な項目の自動入力機能（下記のCUI版を使用） 自動入力 自動撮影＆自動添付 自動入力 自動添付
38. QA • 自動で作成したチケットを手動のバグと区別する – Redmineのトラッカー • 手動のバグ→「バグ」 • 自動のバグ→「エラー送信」 – 区別する理由 • Jenkinsによる自動操作のミスを防止 • 実際のプロジェクトへの混乱のない導入 • マスターアップ直前は選別が必要 自動作成チケットのルール
39. QA 自動作成チケットの例 題名は エラーメッセージまたは スタックトレースの1行目 エラーメッセージ スタックトレース ダンプや直前動画等を 1クリックで開けるリンク
40. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート バグの再現性 を確認
41. Build • 再現確認のための実行 – セーブデータ、リプレイ用スクリプト – 実行用Jenkinsジョブを呼びだす – 複数回実行する（タイムアウト付き） • 実行結果をRedmineチケットに反映 – 同じエラーが発生 • 対象チケットの「自動再現」項目を「はい」 ⇒ 開発者：再現用データを使って確認可能（詳細は修正編） – エラーが発生しない ⇒ 開発者：「再現しなかった」という情報と共に調査 【再現確認の自動化】Jenkinsと連携
42. Build エラー送信経由でJenkinsをキック リプレイデータ • 直前のオートセーブ • リプレイ用スクリプト(.py) • デバッグ設定情報(.ini) • 再現用bat(replay_jenkins.bat) チケット管理システム (Redmine) Jenkins 再現確認 ジョブ実行 自動再現 「はい」
43. QA エラー検知と再現確認の例 エラー検知 再現確認 直前のセーブデータからどこでもリプレイを再生して 特定キャラに話しかけるとエラーになるバグを再現！
44. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 自動化 自動化 自動化 自動化 自動化 自動化 自動化
45. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
46. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 優先度決定 重要度決定
47. QA • 優先度と重要度の違い – 優先度 • 修正を急ぐ必要性 – 高：多くの場所に影響がある – 低：特定の条件がそろわないと起きない/再現率が低い – 重要度 • バグの重大性 – 高：アプリケーションエラーで強制終了 – 低：誤字脱字などの表記ミス » ただし権利表記や製品基準に関わる誤字は重要度高 【優先度・重要度の決定の自動化】
48. QA • 重複数が多い＝広範囲で発生して緊急性が高い • 重複判定 – エラーメッセージの1行目の一致 – スタックトレースの最初の1行目の一致 • 重複数の表示例 重複数で優先度を決定 スタックトレース または エラーメッセージ チ ケ ッ ト 番 号
49. QA • エラーの種類でシンプルに判定 – 例外 • 重要度：高 – ASSERT • 重要度：高 – WARNING • 重要度：中 重要度の自動設定
50. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 担当者決定
51. Build • 機械学習を使ったチケット担当者の自動割り当て – 今回はチャレンジのみで実運用には至らず • 取り組みの概要 – 学習データ：過去、進行中プロジェクトのRedmineデータ • 入力：件名、説明（エラーメッセージ、スタックトレース） • ターゲット：担当者 – アルゴリズム • CNN, Character-level CNN – 出力例 • ユーザ毎の担当者確率 【修正担当者決定の自動化】機械学習
52. Build • 簡単な考察 – ここでの結論 • 方向性は悪くなかったが、 こういうことができる前提としてエラー登録の仕組みと運用が整っ ている – 機械学習導入の労力 • 機能の実装（今回はやってみた） • 結果の検証、調整（今回は途中まで） • 学習を繰り返しながら運用（今回取り組まず） 【修正担当者決定の自動化】機械学習 ⇒ 今回はASSERTマクロ機能（後述）の拡張という別手段で解決 ルールで解決可能な場合はルールに沿った仕組みの方が費用対効果は高い
53. QA 【修正担当者決定の自動化】ASSERTマクロ WARNING ASSERT DEBUGBREAK 例外 例外は13%程度 エラーの全体の87%はアサーション
54. QA DRAGON_ASSERTで担当者を自動割り当て ASSERT_STAGE_SAKAUE(condition, "エラーメッセージ"); エラー送信 どこでもバグ報告 自動設定 修正担当者に直接チケットを届けることが可能！
55. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化
56. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
57. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 デバッグ コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート ローカルでの 再現確認 修正動作確認
58. QA • どこでもリプレイを開発者環境で実行 – 「自動再現」が「はい」のチケットで利用可能 – ダンプ保存場所に作成済みの再現用batを利用 • replay_autotest.bat – 自席PCのオートテスト環境で再現確認 • replay_local.bat – 自席PCのビルドを使って修正確認 【開発者環境での再現・修正確認の自動化】
59. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート
60. QA 【コンバートの自動化】Jenkins コンバート ビルド チェック exe更新 (Nightly Build) スモーク テスト 静的コード 解析 Redmine ステータス 変更 Jenkinsによる自動化 プログラム データ （モデル/サウンドなど） ゲーム に反映 コンバート自動化の詳細は『「龍が如く」の高速デバッグ術 ～そびえ立つバグの山を踏破するための弾丸ワークフロー～』 http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
61. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート チケットを 「確認待ち」
62. QA 修正確認タイミングを通知＆保証する仕組み 【修正の反映タイミング通知の自動化】コンバート予約 コンバート待ち 確認待ち 自 動 コンバート 予約 対応中 Jenkinsで コンバートが成功 Exe更新待ち 自 動 Jenkinsで Exe更新が成功 修正をコミット 最新版ですぐに修正確認が可能！
63. QA 【修正の反映タイミング通知の自動化】コンバート予約 「確認待ち」になったら 確実に修正確認が可能 コンバートの種類を選択して 予約を作成 プログラムの場合はチケット番号をコミット時に指定すれば 自動的にコンバート予約が完了！
64. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化
65. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
66. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 コンバート デグレ確認
67. QA • 入念なデグレチェック体制 – ビルドチェック – 静的解析（VSコード分析・Coverity） – スモークテスト – オートテスト（ゲーム全域をカバー） 【リグレッションテストの自動化】 修正によるデグレ（エンバグ）を自動検出
68. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムへの道 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット デグレ確認 コンバート 修正の 反映待ち ビルドを更新 修正確認 チケットを 「確認済み」
69. Build • どこでもリプレイによる修正確認（Jenkins） – チケットステータスが「確認待ち」になる – Jenkinsが検知 – 最新ビルドに更新 – 「再現確認の自動化」の仕組みで再度実行 • 不具合再発無し ⇒ 「確認済」 • 不具合が再発 ⇒ 「差し戻し」 【自動テストによる修正確認の自動化】
70. Build 【自動テストによる修正確認の自動化】 自 動 差し戻し 自 動 Replay_AutotestJob #123 replay_jenkins.bat 5回再生 チケットID：83 タイムアウト30分 結果：成功 結果：失敗 自 動 Redmine Redmine Jenkins Jenkinsが検知 リプレイジョブを実行 自動リプレイが完走 自動リプレイで エラーが再発 確認済 確認待ち
71. Build • 時間経過による自動確認済（Jenkins） – 前提：日々のオートテスト実行とエラー報告の自動化 により、未修正の問題は継続的に報告され続ける • ⇒ エラー報告が止まったものは解決とみなす – 方針：チケットの更新（自動報告の重複関連付け、作 業者による更新も含む）が一定期間以上無い場合、チ ケットは「確認済」とする • （意味的には「確認済」よりは「再発しない」） – 対応：Jenkinsで定期的にチェック、自動処理 【重複判定による修正確認の自動化】
72. Build 【重複判定による修正確認の自動化】 エラー送信 #84 ステータス：対応中 Redmine_Check_ErrorIssues 2週間以上更新が無い エラー送信 #85 ステータス：対応中 更新を確認 エラー送信 #86 「重複数」を更新(+1) 重複関連付け Jenkins Redmine 自 動 確認済 （再発しない）
73. QA 修正確認の自動化の例 特定キャラに話しかけてエラーにならないことを確認 修正確認の自動化を達成！
74. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
75. QA 修正確認 修正 選別 報告 探索 全自動バグ取りシステムの自動化範囲 チケットを 「確認済み」 バグを発見 バグチケット 作成 担当者決定 チケットを 「確認待ち」 テスト計画 テスト実行 テスト 環境構築 テスト作成 バグの周辺 情報を収集 バグの再現性 を確認 初期担当者が 内容を確認 優先度決定 重要度決定 ローカルでの 再現確認 デバッグ 修正動作確認 コミット 修正の 反映待ち ビルドを更新 修正確認 デグレ確認 コンバート 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化 自動化
76. QA 代表的な自動化機能の適用件数 ゲームタイトル どこでもバグ報告 コンバート予約 エラー送信 全自動化 龍が如く 維新！ 9,338 未計測 未計測 - 龍が如く0 誓いの場所 6,316 7,930 621 - 龍が如く 極 1,931 4,013 未計測 - 龍が如く6 命の詩。 18,529 18,101 8,102 - 龍が如く 極2 10,487 9,836 8,645 - 北斗が如く 8,676 8,096 16,532 - JUDGE EYES：死神の遺言 15,253 13,457 16,930 - 龍が如く7 光と闇の行方 20,478 19,131 29,242 250 いずれかの恩恵をうけてバグ作業フローが効率化！
77. QA バグ１件当たりの作業時間 龍 維新 龍０ 龍極 龍６ 龍極２ 北斗が如く JUDGE EYES 龍７ 全自動バグ取りシステムが1件当たりの作業時間を削減 各自動化の恩恵を 受けたチケット数を 集計してポイント化
78. QA • 全自動化できたバグチケット（純粋な修正除く） – 250件とまだまだ少ない • バグ作業フロー全体の効率化は達成！ – ほぼすべてのバグチケットが自動化のいずれかの 恩恵をうけているため • 今後の課題 – どこでもリプレイの精度向上 • 経過時間の再現 • ランダムのシードの固定化 全自動バグ取りシステムの運用結果
79. QA ゲーム開発で面倒なことを すべて自動化するための スタートライン！ 全自動バグ取りシステムとは
80. QA Build • 「龍が如く」の高速デバッグ術 ～そびえ立つバグの山を踏破するための弾丸ワークフロー～ – http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf • 無料で始める！ 「龍が如く」を面白くするための 高速デバッグログ分析と自動化 – http://www.jasst.jp/symposium/jasst18tokyo/pdf/D4.pdf • 「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成 の取り組みについて – https://www.slideshare.net/SEGADevTech/7-234572005 関連資料
81. QA Build • 社内ヘルプデスクをＡＩで！ フューチャーアーキテクト開発者ブログ – https://future-architect.github.io/articles/20171005/ • GDC 2018 - Tools Tutorial Day: Tools to Reduce Open Bug Count at Media Molecule – https://www.gdcvault.com/play/1025439/Tools-Tutorial-Day-Tools-to – https://www.gdcvault.com/play/1025013/Tools-Tutorial-Day-Tools-to 参考文献