CEDEC2025 長期運営ゲームをあと10年続けるための0から始める自動テスト ~4000項目を50%自動化し、月1→毎日実行にした3年間~

2025-07-22 から 2025-07-24 に開催された CEDEC2025 で発表した資料です。

登壇者: 田原 遥美、小山 竜之介
詳細は以下をご確認ください。
https://cedec.cesa.or.jp/2025/timetable/detail/s67a489537b31a/

Transcript

1. 長期運営ゲームを あと10年続けるための 0から始める自動テスト ~4000項目を50%自動化し、月1→毎日実行にした3年間~ 1 株式会社アカツキゲームス 田原 遥美 / 小山 竜之介
2. 自己紹介: 田原遥美 • 業務内容 ◦ サーバーアプリケーション開発 ◦ 社内ツール開発 ◦ QA改善・自動化 • 趣味 ◦ ゲーム ◦ 特撮鑑賞 ◦ 手芸 2
3. 自己紹介: 小山竜之介 • 業務内容 ◦ サーバーアプリケーション開発 ◦ インフラ開発・運用 ◦ QA改善・自動化 ◦ エンジニアチームマネジメント • 趣味 ◦ 家事RTA ◦ ゲームではサポート系やりがち 3
4. はじめに ベストプラクティクス 抽象的な学び 具体的な出来事 事例紹介 3年分の様々なことをギュッと1時間にしています 深掘りたい・気になることがあればコメントにぜひ！ 私たちはこうした！という内容です 4
5. リグレッションテスト自動化の目的 5
6. ❌ 新しい不具合を発見する　⭕ 今ある機能の劣化を防ぐ リグレッションテストを省略 = 基本機能を損なう重大な欠陥のリスク リグレッションテストのコスト → リリースのコスト リグレッションテスト（regression Testing） 変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認 するため、変更実施後、すでにテスト済みのコンポーネントやシステムに対して実行するテスト。 by ISTQB リグレッションテストとリリース 6
7. 増え続ける機能とリリースコスト 変更 テスト 変更 リグレッション テスト テスト 変更 リグレッション テスト リグレッション テスト テスト 機能の数 リグレッションテストの 項目数 ≒ 開発するたび、リリースコストが雪だるま式に増加 7
8. E2Eテスト（End to End Testing） 実稼働環境と同様の状況でビジネス プロセスを最初から最後までテストするテストの一種。 by ISTQB 私たちのリグレッションテスト自動化状況 手動テスト リリース前に1度実行 自動化済み 変更時にCIで実行 E2E テスト 統合テスト 単体テスト 8
9. 増え続ける機能とリリースコスト 機能の数 リグレッションテストの 項目数 ≒ 開発するたび、リリースコストが雪だるま式に増加 約4,000項目 約40人日！ 手動E2Eテストが1~2ヶ月のリリースごとに 9
10. リグレッションテストのコスト増加による影響 1 小規模な変更でも即時リリースが困難になり、 価値の提供が遅れる 2 複数の変更をまとめてリリースする運用となり、 リリースサイクルが長期化 3 テストが開発の最終段階に集中し、 手戻りコストが増加 10
11. リグレッションテスト自動化の目的 自動化により... 変更の規模によらず、 安定したリリースサイクルを、 低コストで！ 11
12. 実績のまとめ 12
13. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 13
14. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 14
15. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 15
16. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 16
17. 技術紹介 17
18. 自動テストシステム 全体像 Icons by icons8
 18
19. 技術選定 Icons by icons8
 オンプレ Mac 既存のビルドパイプラインに乗れる (クラウドなどと比べ) トライアンドエラーがしやすい 19
20. 技術選定 Icons by icons8
 Android エミュレータ 管理不要 スケールが容易 20
21. 技術選定 Icons by icons8
 Airtest & Poco プロダクトに対応 テストスクリプトがシンプル Airtest IDEのサポート 21
22. テスト基盤（テスト管理システム） 自作のテスト基盤について 入力 アプリ起動から タイトルへ遷移 タイトル画面の 検証 タイトル画面検証 アプリ起動から タイトルへ遷移 チュートリアル 突破 商品購入検証 ショップ機能検証 テスト実行 テストシナリオ 実行 シナリオの レポート作成 シナリオが残っている場合 次のシナリオを実行 準備 エミュレーター 起動 アプリの インストール アプリの起動 後処理 結果を集計 レポートURLを含めた 結果をSlackで通知 S3にレポートを送 信 エミュレーター 停止 22
23. 関係メンバーの紹介 23
24. 自動テストチームの人数変遷 調査・実験 フェーズ 0.5~1人 基盤整備 2人 一時ヘルプ 基盤整備 シナリオ量産 基盤整備2人 シナリオ量産2人 （1人ヘルプ） 運用・保守 2人 24
25. 自動テストチーム(運用段階) サーバーエンジニア 基盤整備 デバッグAPI開発 シナリオレビュー QAエンジニア シナリオ作成 デバッグAPI開発 テストレポート提出 QA担当 項目作成 取りまとめ リリース前QAチーム 自動テストチーム 25
26. プロダクト開発体制 開発チーム内QA 開発チームで担当する機能が スコープ 開発チーム（スクラム） エンジニア、デザイナー、 プランナー、QA リリース前QAチーム リリース前に総合的なテストを行う リリースに含まれる全ての機能が スコープ 26
27. 開発全体での立ち位置 自動テストチーム 自動テストを作成・提供 開発チーム 開発チーム リリース前QAチーム リグレッションテスト作成 協力 27
28. 運用フロー 28
29. 運用フロー: デイリー実行 開発チーム その日の開発ブランチで ビルドしたアプリで 毎晩自動テストを実行 レポートURL付 き結果通知 翌日に自動テストチー ムが確認し、 開発チームへFB Icons by icons8
 29
30. 運用フロー: リリース前 自動テスト準備 テスト実行・分析 リリース 実施シナリオ選定 変更の確認 マスタデータの調整 テスト結果の精査 不具合発見時の報告 開発終了 手動テストと合わせ リリース判断 30
31. 本格導入までの4年間のタイムライン 31
32. 0年目: きっかけ プロジェクト リーダー 開発 ディレクター ここから 10年続ける！ 常に改善を 続けていこう！ リグレッションテスト は増え続けるから 早めに備えよう！ 隙間で 自動テストについて 調べ始める 32
33. 0年目: 0から始める自動テスト E2E × モバイル × ゲーム 情報ほぼ0 自動テストの知識0 33
34. 0年目: 調査開始 テスト実行環境 テスト フレームワーク テスト 実行デバイス Appium Airtest … ローカル端末 クラウド エミュレータ … オンプレPC クラウド テストサービス … 調査/比較 34
35. 0年目: 本格的に進めたいが... 機能開発の優先度が高い 不確実すぎて コストをかけにくい 35
36. 0年目: 自動テストチーム(一人)誕生 開発 ディレクター あと10年続けるなら リグレッションテストが 課題になりそうです！ よし、まずは少人数で 改善チームを 立ち上げてみよう 以前から気になっていた 自動テストを小さく始め てみませんか？ 36
37. 本格導入までのタイムライン 基盤構築 & 運用フロー整備 & シナリオ量産準備 2年 シナリオ量産開始 & 基盤の強化 手動→自動への置き換え & 全シナリオの自動化を完了 1年 3年 37
38. 本格導入までのタイムライン 基盤構築 & 運用フロー整備 & シナリオ量産準備 2年 シナリオ量産開始 & 基盤の強化 手動→自動への置き換え & 全シナリオの自動化を完了 1年 3年 38
39. 1年目: 基盤構築 並列実行 未対応 Icons by icons8
 39
40. 1年目: チュートリアルシナリオの実証実験 ※画像はAIで生成されたイメージです チュートリアルのダイアログの 画像変更等を検知 1pxもずれがないロングタップで 意図しないダイアログが 出てしまうなど チュートリアルはボリュームが多く 変更が少ないとはいえ 最初に試すのには適していなかった 40
41. 1年目: 運用フロー整備 追加変更時のフローは？ 最初は自動テストチームで シナリオの修正対応？ 最終的にはQAチームで シナリオの修正を 出来ると良さそう テスト項目に追加・変更が あったらどこで対応する？ デグレードが見つかったら どう対応する？ 41
42. 1年目: 運用フロー整備 QA チーム 自動テスト チーム どうやって 動いているの？ 一緒に動かして みましょう！ なるほど！ じゃあこう進め ると良さそう！ ハンズオン実施 AirtestIDEで簡単なシナリオを作り 動かしてレポート作成まで行った QA チーム 42
43. 1年目：シナリオ量産準備 A B C 重要度⤴ 重要度⤵ 重要な動作 基本機能 細かい項目 約8,000項目 約4,000項目 約4,000〜8,000項目と膨大 43
44. 1年目: シナリオ量産準備 シナリオを作成時に 項目の抜け漏れが 発生しそう 量が多いので 自動↔手動の移行を 簡単にしたい 自動テストが行えない時の 対策をしたい 全ての項目を対象にすると シナリオ作成工数が 大きすぎる 項目書をシナリオに 変換したい （楽にしたい） 44
45. 1年目: シナリオ量産準備 シナリオを作成時に 項目の抜け漏れが 発生しそう 量が多いので 自動↔手動の移行を 簡単にしたい 自動テストが行えない時の 対策をしたい 全ての項目を対象にすると シナリオ作成工数が 大きすぎる 項目書をシナリオに 変換したい （楽にしたい） 45
46. スコープを絞る A B C 重要度⤴ 重要度⤵ 重要な動作 基本機能 細かい項目 約8,000項目 約4,000項目 リリースに必要な項目AとBの約4,000項目の内 自動化可能な約2,000項目をスコープとした 46
47. スコープを絞る 自動化の可否 検証対象を適切に減らす アニメーション、音など 機能の振る舞い OSごとの振る舞い オブジェクトの存在、文字、 静止画、テクスチャ名など OSによる差異 47
48. 1年目: シナリオ量産準備 シナリオを作成時に 項目の抜け漏れが 発生しそう 量が多いので 自動↔手動の移行を 簡単にしたい 自動テストが行えない時の 対策をしたい 全ての項目を対象にすると シナリオ作成工数が 大きすぎる 項目書をシナリオに 変換したい （楽にしたい） 48
49. 手動↔自動の移行負荷を下げる 期待結果 手動検証結果 自動検証結果 ステータスが正しいこと - OK ◦◦のSEが鳴ること OK - XXのアイコンが表示されていること - OK 手動/自動で項目書を共有する 49
50. 1年目: シナリオ量産準備 シナリオを作成時に 項目の抜け漏れが 発生しそう 量が多いので 自動↔手動の移行を 簡単にしたい 自動テストが行えない時の 対策をしたい 全ての項目を対象にすると シナリオ作成工数が 大きすぎる 項目書をシナリオに 変換したい （楽にしたい） 50
51. 自動テストのブラックボックス化を防ぎたい 将来的にQAメンバーも シナリオを書けるようにしたい！ QAエンジニア以外から見た 自動テストのブラックボックス化を防ぎたい 学習コストを低くする 51
52. 自動テストのブラックボックス化を防ぎたい 複雑な独自関数などを作らず AirtestIDE上で作れる範囲に シンプルな構文を意識 シナリオの設計 コーディングルールを定める 学習コストを下げるために 52
53. シナリオの設計について マスタデータの変更への 強度を意識 開発チームと 環境を共有 データの変更が頻繁 マスタの変更により テストがこける シナリオで工夫が必要 53
54. マスタデータの変更への強度を意識 古く変更が少ない要素 を使用する 時間がフックの機能を 把握する リストの上（最新）から使うと 変更される可能性が高い シナリオ実装時に存在していた ダイアログ等が時間が経つと出ない 逆に想定していないタイミングで ダイアログが出てしまい 失敗するなど 54
55. シナリオをシンプルに AirtestIDEで作りやすいように 独自関数などをなるべく作らない 単純なIF分岐や回数制限付きの ループ処理のみに留める シナリオの可読性 メンテナンス性を確保する 55
56. 項目書をシナリオに変換するツール 自動テスト用に 項目の順番を入れ替えた 項目書 シナリオのテンプレート .py 項目書をシナリオのテンプレートに変換するツールを作成 56
57. 項目書をシナリオに変換するツール Poco操作の要素名を 網羅して対応させることは 低コストでは難しい 1つの項目に 複数の手順が内包されている パターンが多い 量産準備を低コストで楽にするために 一発で完全なシナリオを作るのではなく補助的役割にとどめ コメントに沿って実装していく形にし 抜け漏れ、入力ミスを減らすことにフォーカス 定数名など規律を守りたい要素もあらかじめテンプレートとして入れる 57
58. 項目書をシナリオに変換するツール 変換例 # -*- encoding=utf8 -*- from airtest.core.api import * ST.FIND_TIMEOUT = 60 # assert_exists() のタイムアウト設定（秒） WAIT_TIME = 10 # poco("hoge").wait(WAIT_TIME) 任意に設定できるタイムアウト設定（秒） # [1] : ▲▲ 画面に遷移すること # assert_exists(Template(r" 画像パスを入れてください "), "[1] ▲▲ 画面に遷移すること ") # [2] : ⚪⚪が表示されていること # assert_exists(Template(r" 画像パスを入れてください "), "[2] ⚪⚪が表示されているこ と") 58
59. 本格導入までのタイムライン 基盤構築 & 運用フロー整備 & シナリオ量産準備 2年 シナリオ量産開始 & 基盤の強化 手動→自動への置き換え & 全シナリオの自動化を完了 1年 3年 59
60. 2年目: シナリオ量産 Icons by icons8 自動テストチーム シナリオ作成メンバー増員 .py .py .py 結果通知 上手く 動かなければ 調整 できたものからCIに載せる 60
61. 2年目: マスタデータによるテストの不安定さ マスタデータの変更への 強度を意識 開発チームと 環境を共有 データの変更が頻繁 マスタの変更により テストがこける シナリオで工夫が必要 再掲 61
62. 2年目: DebugAPIによるマスタデータ安定化 シナリオ上から Debug APIを叩いて マスタデータの状態を変更 Debug API 62
63. 2年目: 長いテスト準備 レベル上げ作業 キャラ獲得 育成素材の獲得 シナリオで再現すると時間がかかる 複数のシナリオで 同じような処理を何度も行う レベルMAXキャラクターを 複数所持している状態にするには 63
64. 2年目: Debug API によるテスト準備効率化 シナリオ上から Debug APIを叩いて マスタ・ユーザーの状態を変更 Debug API 64
65. 2年目: テスト実行の並列化 .py .py .py .py .py 1シナリオ ✖ 5min 5min .py .py .py 4シナリオ ✖ 5min 20min テスト時間の短縮 65
66. 2年目: アセットDLが長い インターネット それぞれの端末でDL インターネット PUSH DL 事前にPCにDLしたアセットを 各端末に配置 66
67. 本格導入までのタイムライン 基盤構築 & 運用フロー整備 & シナリオ量産準備 2年 シナリオ量産開始 & 基盤の強化 手動→自動への置き換え & 全シナリオの自動化を完了 1年 3年 67
68. 3年目: 手動テスト→自動テストへの不安 チュートリアルシナリオを 毎日実行してみよう！ 本当に機械に任せても 大丈夫？ 大丈夫そうだから 毎日実行で様子を見よう！ 68
69. 3年目: テスト結果の分析 シナリオ名 バージョン 結果 エラー内容 … SQLite 分析 結果をSQLiteに蓄積し スプレッドシートで分析 スプレッドシート 69
70. 3年目: シナリオ作成一旦完了、運用フェーズへ 70
71. 展望 71
72. 準備 展望: 手動テストの準備効率化 準備 実行 準備 実行 自動化 72
73. 展望: テスト結果の分析強化 テス ト テス ト テス ト テス ト テス ト テス ト テス ト テス ト テス ト テスト ver. A テス ト テス ト テス ト テス ト テス ト テス ト テス ト テス ト テス ト テスト ver. B 確認が大変 ver. AはOK ver. BはNG A→Bの比較は... 分析ツール 73
74. 展望: 持続可能な自動テスト体制 デイリーごと テスト結果の フィードバック リリースごと テスト結果の フィードバック シナリオの 追加・変更 開発チームで 回せるように QAチームで 回せるように QAチームや 機能開発者で 対応できるように 74
75. 実績詳細 75
76. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 76
77. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 77
78. 自動テストで検知した一例 テクスチャのずれ 見た目の変化が大きくわかりやすい ダイアログ画像 / 文章の デグレード 注意深く見ないと見逃しやすい 1px単位の操作など 特殊条件のバグ 人間による再現が難しい 特定機能のアセット/マスタ の不整合 特定機能に入らないと検知できない 78
79. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 79
80. テスト項目50%自動化、工数50%削減 24 人日 18 人日 12〜14 人日 手動/自動 並走期間 80
81. 実績のまとめ 1 毎日夜間に最新ビルドで自動リグレッションテストを実行し 翌朝に結果を確認できる運用の確立 2 約4,000項目のうち50%（約2,000項目）を自動化し 手動工数を50%削減 3 自動テストの成功により、他テスト自動化の相談が増加 81
82. 「自動テスト」という選択肢の追加 パフォーマンステストや インゲームテストを 自動化できます？ リグレッションテストの稼働に伴い、他のテストの自動化の相談が増加 リグレッションテストが 自動化できました！ 他にも応用できそう プロジェクトメンバー 82
83. 「自動テスト」という選択肢の追加 パフォーマンステストや インゲームテストを 自動化できます？ 自動化可能か 項目を精査しましょう！ プロジェクトメンバー リグレッションテストの稼働に伴い、他のテストの自動化の相談が増加 83
84. 「自動テスト」という選択肢の追加 どうテストすべきか 本当に意味のある テストか 自動化の相談を受けた際に検証項目を見直し 精査するフェーズを設ける 本来やらなくても良かった項目を 削減するチャンス 84
85. まとめ 85
86. 増え続ける機能とリリースコスト 機能の数 リグレッションテストの 項目数 ≒ 開発するたび、リリースコストが雪だるま式に増加 約4,000項目 約40人日！ 手動E2Eテストが1~2ヶ月のリリースごとに 再掲 86
87. リグレッションテストのコスト増加による影響 1 小規模な変更でも即時リリースが困難になり、 価値の提供が遅れる 2 複数の変更をまとめてリリースする運用となり、 リリースサイクルが長期化 3 テストが開発の最終段階に集中し、 手戻りコストが増加 再掲 87
88. まとめ なぜ自動化をしたのか 約4,000項目に及ぶ 膨大なテスト項目 テストコスト増加 による影響 「いつでもリリースできる体制」 づくりが必要だった リグレッションテストの 自動化率50％（約2,000項目）を達成 テスト工数を約50%削減 日時実行体制の構築と信頼性の確保 自動化を軸にした運用フローの改善 開発の柔軟性・リリースサイクルの 改善に貢献 88