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

by SEGADevTech

Slide 1

Slide 1 text

「龍が如くスタジオ」の QAエンジニアリング技術を結集した全自動バグ取りシステム株式会社セガ阪上直樹 Ⅹ 粉川貴至

Slide 2

Slide 2 text

QA Build 自己紹介株式会社セガ第1事業部(龍が如くスタジオ) QAエンジニア阪上直樹株式会社セガ開発技術部ビルドエンジニア粉川貴至

Slide 3

Slide 3 text

QA みなさんバグは好きですか？

Slide 4

Slide 4 text

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年ゲーム規模の拡大とともにバグチケット数も増加傾向

Slide 5

Slide 5 text

QA つらいですね… でも大丈夫！

Slide 6

Slide 6 text

QA 本講演が終わるころにはバグをハグしたくなります！

Slide 7

Slide 7 text

QA バグ作業フローの自動化本講演のテーマ

Slide 8

Slide 8 text

QA 修正確認修正選別報告探索バグ作業フロー（手動の場合）チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバート

Slide 9

Slide 9 text

QA • バグやタスクを一括管理するシステム – 龍が如くスタジオではRedmineを使用 • バグチケットのステータスの流れチケット管理システムについて確認待ち対応中新規差し戻し確認済修正開始修正完了修正確認OK 修正確認NG チケット管理システムの詳細は『「龍が如く」の高速デバッグ術～そびえ立つバグの山を踏破するための弾丸ワークフロー～』 http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf

Slide 10

Slide 10 text

QA • ゲームの開発効率を上げるために最重要 – バグの処理作業に時間がかかると最悪発売延期 – 自動化がデバッグ期間の短縮につながる – 単純なバグ取りに人的リソースをかけたくないなぜバグ作業フローの自動化するのか？全自動バグ取りシステムを作ろう！

Slide 11

Slide 11 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 12

Slide 12 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 13

Slide 13 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートテスト環境構築

Slide 14

Slide 14 text

QA 【テスト環境構築の自動化】オートテスト帰宅前に各PCでオートテストクライアントを実行設定ファイル(Excel)から iniを生成最新ビルドを取得ゲームを自動起動 (iniファイルのシナリオ/条件) エラー通知

Slide 15

Slide 15 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト環境構築バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートテスト実行テスト作成

Slide 16

Slide 16 text

QA • どこでもリプレイシステム – 自動テスト作成・実行するためのシステム – 手動プレイをリプレイ用スクリプトとして記録・再生 – プログラミング知識なしで自動テストが作成可能 – リプレイ用スクリプトはPythonを採用 • 後から条件分岐や繰り返し処理を追加可能 • 将来的な画像認識や機械学習との連携を想定【テスト作成・実行の自動化】

Slide 17

Slide 17 text

QA どこでもリプレイシステムのデモ手動プレイを記録中リプレイ再生中手動プレイ中にどこでも記録・リプレイが可能！

Slide 18

Slide 18 text

QA 外部ツールゲーム内どこでもリプレイエディタ GUI(C#) WebSocket サーバどこでもリプレイシステム（記録）ゲーム動作をアクション単位でスクリプト化ゲームを手動でプレイ

Slide 19

Slide 19 text

QA 外部ツールゲーム内どこでもリプレイシステム（再生）アクションを指定どこでもリプレイ CUI(Python) 結果通知結果 JSONで受け渡し WebSocket サーバアクション Pad情報どこでもリプレイエディタ GUI(C#) 行ごとの結果 p y ファイル path(x,y,z)をアクション(JSON)に変換

Slide 20

Slide 20 text

QA アクションとゲームの入出力アクションゲームステート疑似Pad情報のみ手動プレイとほぼ同じ動作であることを保証自動テストの詳細は『「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて』 https://www.slideshare.net/SEGADevTech/7-234572005

Slide 21

Slide 21 text

QA どこでもリプレイシステムのテスト範囲シナリオクリアコリジョン抜けパフォーマンス計測アイテムコンプリート UIガチャ押しミニゲームリプレイ用スクリプトの組み合わせプレイログの機械学習ランダム正確探索的ユーザープレイに近いバグを検知（研究中）新規バグエンバグ (デグレ)

Slide 22

Slide 22 text

QA ランダムなテストの例コリジョン抜け (酔拳のような動き) バトル用ミニゲーム用ポーズメニュー用ゲームの状況によって自動パッド操作を切り替えアドベンチャー用

Slide 23

Slide 23 text

QA 探索的テストの例（ログ活用）手動・自動テストのリプレイスクリプトを登録ログサーバ Elasticsearch 検索でマッチしたリプレイスクリプトを実行開始・終了座標、シナリオ、ステージ等でタグ付け

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Build • オートテストクライアントとJenkinsの使い分け – オートテストクライアント • 利用者（テスト協力者）が扱いやすい – 利用PCで実行状態がわかる – 起動前と終了後の処理を正しく行う • 開発の空き時間での運用 – Jenkinsからの実行 • オートテスト管理者が扱いやすい – より複雑なオートテスト制御を行う • 24時間稼働している前提での運用【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト 24時間稼働している前提での運用開発の空き時間での運用サブシナリオのテスト • 1つ30分～2時間程度のサブシナリオが50以上 • 全サブシナリオを効率的に実行したい

Slide 26

Slide 26 text

Build • Jenkinsからより複雑なオートテスト制御を行う – 実行内容の制御 • テスト対象の指定 – セーブデータ、リプレイ用スクリプト • タイムアウト設定 – 実行PCの制御 • 1つ1つのサブシナリオテストを順に空きPCに割り当てて実行していく【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト

Slide 27

Slide 27 text

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万回弱実行

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートバグを発見

Slide 30

Slide 30 text

QA 【エラー検知の自動化】 • エラー検知の種類 – 例外（アプリケーションエラー） – ASSERT • 例外と同じくエラー扱い – WARNING • 開発モードは継続可能 • テストではエラー扱い – テスト結果分析 • どこでもログ分析で進行不能等を見える化適切なアサーションを大量に入れるどこでもログ分析の詳細は『無料で始める！「龍が如く」を面白くするための高速デバッグログ分析と自動化』 http://jasst.jp/symposium/jasst18tokyo/pdf/D4.pdf ©SEGA

Slide 31

Slide 31 text

QA オートテストのエラー検出数と割合オートテスト 8,102件 18.6% 龍が如く6 命の詩。 (ランダム＋パス) 龍が如く7 光と闇の行方 (ランダム＋Python) オートテスト手動テスト JUDGE EYES：死神の遺言 (ランダム＋Lua) オートテスト 16,930件 33.4% ※2020年7月に集計オートテスト 29,242件 68.5%

Slide 32

Slide 32 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバート自動化自動化自動化自動化

Slide 33

Slide 33 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 34

Slide 34 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートバグの周辺情報を収集

Slide 35

Slide 35 text

QA 龍が如くスタジオのクラッシュレポート機能【バグ周辺情報収集の自動化】エラー送信ゲーム実行中に例外発生！ネットワークドライブ • ダンプ • ログ • スタックトレース • スクリーンショット • 直前の動画 • リプレイデータメール送信 • ダンプ表示batのURL • スタックトレース • リビジョンチケット管理システム (Redmine) ログサーバ 1エラー数百MB～数GB

Slide 36

Slide 36 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートバグチケット作成

Slide 37

Slide 37 text

QA 【チケット作成の自動化】どこでもバグ報告バグ報告に必要な項目の自動入力機能（下記のCUI版を使用）自動入力自動撮影＆自動添付自動入力自動添付

Slide 38

Slide 38 text

QA • 自動で作成したチケットを手動のバグと区別する – Redmineのトラッカー • 手動のバグ→「バグ」 • 自動のバグ→「エラー送信」 – 区別する理由 • Jenkinsによる自動操作のミスを防止 • 実際のプロジェクトへの混乱のない導入 • マスターアップ直前は選別が必要自動作成チケットのルール

Slide 39

Slide 39 text

QA 自動作成チケットの例題名はエラーメッセージまたはスタックトレースの1行目エラーメッセージスタックトレースダンプや直前動画等を 1クリックで開けるリンク

Slide 40

Slide 40 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートバグの再現性を確認

Slide 41

Slide 41 text

Build • 再現確認のための実行 – セーブデータ、リプレイ用スクリプト – 実行用Jenkinsジョブを呼びだす – 複数回実行する（タイムアウト付き） • 実行結果をRedmineチケットに反映 – 同じエラーが発生 • 対象チケットの「自動再現」項目を「はい」 ⇒ 開発者：再現用データを使って確認可能（詳細は修正編） – エラーが発生しない ⇒ 開発者：「再現しなかった」という情報と共に調査【再現確認の自動化】Jenkinsと連携

Slide 42

Slide 42 text

Build エラー送信経由でJenkinsをキックリプレイデータ • 直前のオートセーブ • リプレイ用スクリプト(.py) • デバッグ設定情報(.ini) • 再現用bat(replay_jenkins.bat) チケット管理システム (Redmine) Jenkins 再現確認ジョブ実行自動再現「はい」

Slide 43

Slide 43 text

QA エラー検知と再現確認の例エラー検知再現確認直前のセーブデータからどこでもリプレイを再生して特定キャラに話しかけるとエラーになるバグを再現！

Slide 44

Slide 44 text

Slide 45

Slide 45 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 46

Slide 46 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバート優先度決定重要度決定

Slide 47

Slide 47 text

QA • 優先度と重要度の違い – 優先度 • 修正を急ぐ必要性 – 高：多くの場所に影響がある – 低：特定の条件がそろわないと起きない/再現率が低い – 重要度 • バグの重大性 – 高：アプリケーションエラーで強制終了 – 低：誤字脱字などの表記ミス » ただし権利表記や製品基準に関わる誤字は重要度高【優先度・重要度の決定の自動化】

Slide 48

Slide 48 text

QA • 重複数が多い＝広範囲で発生して緊急性が高い • 重複判定 – エラーメッセージの1行目の一致 – スタックトレースの最初の1行目の一致 • 重複数の表示例重複数で優先度を決定スタックトレースまたはエラーメッセージチケット番号

Slide 49

Slide 49 text

QA • エラーの種類でシンプルに判定 – 例外 • 重要度：高 – ASSERT • 重要度：高 – WARNING • 重要度：中重要度の自動設定

Slide 50

Slide 50 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバート担当者決定

Slide 51

Slide 51 text

Build • 機械学習を使ったチケット担当者の自動割り当て – 今回はチャレンジのみで実運用には至らず • 取り組みの概要 – 学習データ：過去、進行中プロジェクトのRedmineデータ • 入力：件名、説明（エラーメッセージ、スタックトレース） • ターゲット：担当者 – アルゴリズム • CNN, Character-level CNN – 出力例 • ユーザ毎の担当者確率【修正担当者決定の自動化】機械学習

Slide 52

Slide 52 text

Build • 簡単な考察 – ここでの結論 • 方向性は悪くなかったが、こういうことができる前提としてエラー登録の仕組みと運用が整っている – 機械学習導入の労力 • 機能の実装（今回はやってみた） • 結果の検証、調整（今回は途中まで） • 学習を繰り返しながら運用（今回取り組まず）【修正担当者決定の自動化】機械学習 ⇒ 今回はASSERTマクロ機能（後述）の拡張という別手段で解決ルールで解決可能な場合はルールに沿った仕組みの方が費用対効果は高い

Slide 53

Slide 53 text

QA 【修正担当者決定の自動化】ASSERTマクロ WARNING ASSERT DEBUGBREAK 例外例外は13%程度エラーの全体の87%はアサーション

Slide 54

Slide 54 text

QA DRAGON_ASSERTで担当者を自動割り当て ASSERT_STAGE_SAKAUE(condition, "エラーメッセージ"); エラー送信どこでもバグ報告自動設定修正担当者に直接チケットを届けることが可能！

Slide 55

Slide 55 text

Slide 56

Slide 56 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 57

Slide 57 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定デバッグコミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートローカルでの再現確認修正動作確認

Slide 58

Slide 58 text

QA • どこでもリプレイを開発者環境で実行 – 「自動再現」が「はい」のチケットで利用可能 – ダンプ保存場所に作成済みの再現用batを利用 • replay_autotest.bat – 自席PCのオートテスト環境で再現確認 • replay_local.bat – 自席PCのビルドを使って修正確認【開発者環境での再現・修正確認の自動化】

Slide 59

Slide 59 text

Slide 60

Slide 60 text

QA 【コンバートの自動化】Jenkins コンバートビルドチェック exe更新 (Nightly Build) スモークテスト静的コード解析 Redmine ステータス変更 Jenkinsによる自動化プログラムデータ（モデル/サウンドなど）ゲームに反映コンバート自動化の詳細は『「龍が如く」の高速デバッグ術～そびえ立つバグの山を踏破するための弾丸ワークフロー～』 http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf

Slide 61

Slide 61 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道チケットを「確認済み」バグを発見バグチケット作成担当者決定テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバートチケットを「確認待ち」

Slide 62

Slide 62 text

QA 修正確認タイミングを通知＆保証する仕組み【修正の反映タイミング通知の自動化】コンバート予約コンバート待ち確認待ち自動コンバート予約対応中 Jenkinsでコンバートが成功 Exe更新待ち自動 Jenkinsで Exe更新が成功修正をコミット最新版ですぐに修正確認が可能！

Slide 63

Slide 63 text

QA 【修正の反映タイミング通知の自動化】コンバート予約「確認待ち」になったら確実に修正確認が可能コンバートの種類を選択して予約を作成プログラムの場合はチケット番号をコミット時に指定すれば自動的にコンバート予約が完了！

Slide 64

Slide 64 text

Slide 65

Slide 65 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 66

Slide 66 text

Slide 67

Slide 67 text

QA • 入念なデグレチェック体制 – ビルドチェック – 静的解析（VSコード分析・Coverity） – スモークテスト – オートテスト（ゲーム全域をカバー）【リグレッションテストの自動化】修正によるデグレ（エンバグ）を自動検出

Slide 68

Slide 68 text

QA 修正確認修正選別報告探索全自動バグ取りシステムへの道バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミットデグレ確認コンバート修正の反映待ちビルドを更新修正確認チケットを「確認済み」

Slide 69

Slide 69 text

Build • どこでもリプレイによる修正確認（Jenkins） – チケットステータスが「確認待ち」になる – Jenkinsが検知 – 最新ビルドに更新 – 「再現確認の自動化」の仕組みで再度実行 • 不具合再発無し ⇒ 「確認済」 • 不具合が再発 ⇒ 「差し戻し」【自動テストによる修正確認の自動化】

Slide 70

Slide 70 text

Build 【自動テストによる修正確認の自動化】自動差し戻し自動 Replay_AutotestJob #123 replay_jenkins.bat 5回再生チケットID：83 タイムアウト30分結果：成功結果：失敗自動 Redmine Redmine Jenkins Jenkinsが検知リプレイジョブを実行自動リプレイが完走自動リプレイでエラーが再発確認済確認待ち

Slide 71

Slide 71 text

Build • 時間経過による自動確認済（Jenkins） – 前提：日々のオートテスト実行とエラー報告の自動化により、未修正の問題は継続的に報告され続ける • ⇒ エラー報告が止まったものは解決とみなす – 方針：チケットの更新（自動報告の重複関連付け、作業者による更新も含む）が一定期間以上無い場合、チケットは「確認済」とする • （意味的には「確認済」よりは「再発しない」） – 対応：Jenkinsで定期的にチェック、自動処理【重複判定による修正確認の自動化】

Slide 72

Slide 72 text

Build 【重複判定による修正確認の自動化】エラー送信 #84 ステータス：対応中 Redmine_Check_ErrorIssues 2週間以上更新が無いエラー送信 #85 ステータス：対応中更新を確認エラー送信 #86 「重複数」を更新(+1) 重複関連付け Jenkins Redmine 自動確認済（再発しない）

Slide 73

Slide 73 text

QA 修正確認の自動化の例特定キャラに話しかけてエラーにならないことを確認修正確認の自動化を達成！

Slide 74

Slide 74 text

QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ全自動バグ取りシステムへの道（目次）

Slide 75

Slide 75 text

QA 修正確認修正選別報告探索全自動バグ取りシステムの自動化範囲チケットを「確認済み」バグを発見バグチケット作成担当者決定チケットを「確認待ち」テスト計画テスト実行テスト環境構築テスト作成バグの周辺情報を収集バグの再現性を確認初期担当者が内容を確認優先度決定重要度決定ローカルでの再現確認デバッグ修正動作確認コミット修正の反映待ちビルドを更新修正確認デグレ確認コンバート自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化自動化

Slide 76

Slide 76 text

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 いずれかの恩恵をうけてバグ作業フローが効率化！

Slide 77

Slide 77 text

QA バグ１件当たりの作業時間龍維新龍０龍極龍６龍極２北斗が如く JUDGE EYES 龍７全自動バグ取りシステムが1件当たりの作業時間を削減各自動化の恩恵を受けたチケット数を集計してポイント化

Slide 78

Slide 78 text

QA • 全自動化できたバグチケット（純粋な修正除く） – 250件とまだまだ少ない • バグ作業フロー全体の効率化は達成！ – ほぼすべてのバグチケットが自動化のいずれかの恩恵をうけているため • 今後の課題 – どこでもリプレイの精度向上 • 経過時間の再現 • ランダムのシードの固定化全自動バグ取りシステムの運用結果

Slide 79

Slide 79 text

QA ゲーム開発で面倒なことをすべて自動化するためのスタートライン！全自動バグ取りシステムとは

Slide 80

Slide 80 text

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 関連資料

Slide 81

Slide 81 text

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 参考文献