プロセスの目線からみる「自動テストの安定化」

2026/03のAutify コミュニティイベントでの登壇資料です。

テスト自動化の技術的なノウハウではなく、プロセスと組織の視点から自動テストの安定化を論じたのセッション。「ツールを入れたのに定着しない」という現場あるあるの原因を、実体験に基づくアンチパターンを紹介しています。

Transcript

1. AI powered Quality Engineering Platform 2024.06.20 Autify Pro Service プロセスの目線からみる「自動テストの安定化」 AI powered Quality Engineering Platform
2. 自己紹介 オーティファイ株式会社 Pro Service Team マネージャー ・テストエンジニア→第三者検証企業の 　マネージャーを経てAutifyへ入社 ・主として品質・自動化のコンサルティングを務める 逆井賢（Satoshi Sakasai） 組織内での職責（ QAコンサルタント）について コンサルタント 　プロセス改善や自動化 　導入支援などで貢献 エンジニア 　テスト自動化技術を 　駆使し貢献 　 ☝こっち 連携
3. 本日お話しすること △ エンジニアリング ◎ プロセス、やりかた
4. 前置き① 自動テストの安定化は、様々なアンチパターンとの戦い
5. 前置き② 忘れがちなこと よくする プロセスの課題を 自動化で改善する と…単純に考えがちだが、「テスト自動化」自体も 「改善の余地があるプロセス」のはずである
6. 本日のアプローチ テスト自動化の要素（≒安定させたいこと）を切り分けてみる モノ ヒト カネ 古典的な分け方 … ・実装された 自動テスト自体 とその提供価値 ・技術的難しさ ・環境要因 ・責任者の理解 ・実装担当者と リテラシー ・メンテナンス　 要員、体制 ・自動化予算 ・採用ツールと 料金プラン ・ROI検討
7. 事実 自動化の「モノ」の要素には、明確なベストプラクティスがある（以下、例） ア ｜ キ テク チャ テ ク ノ ロ ジ 実装のルール ミチミチのスライドごめんなさい（詳細は本日のテーマからは割愛。。） 例：ユーザ登録テストの自動化テストシナリオ 通常ﾕｰｻﾞは登録できる ﾌﾞﾗｯｸﾘｽﾄ登録できない 未成年は登録できない テスト前の状態に データを戻す テストデータ 前処理 テスト 後処理 テストデータ 「XXXX」の アドレス使用し ユーザ登録開始 登録OK 登録不可 登録不可 シナリオ名 参 照 他の自動化シナリオ よく使うステップは共通化されている 平易な シナリオ名 使うデータが 外部化 クリンナップ ステップがある 他のテストシナリオから独立し、依存関係がない 継続的に、自動で測定できるツール 使い方（運用）のルール UIのテストは極力省く（壊れやすい） 並列実行できるツールと環境 あくまで「動き（ふるまい）」をテスト 内部構造には着目しない セマンティックな要素を指定する 統合済みのシステムに適用する 改修サイクル初期から運用開始する 変更が多い機能群に適用しない 失敗はすぐチェック、修正する
8. その上で、もう一度アプローチ 「モノ」がちゃんと動くような「ヒト」「カネ」って成り立ってますか モノ ヒト カネ ベスト プラクティスに 則って 作られ、 維持される 「実体」 ・どういう体制で 分担するのか？ ・必要なスキル セットは何か？ etc.. ・どういう予算構 成で挑むか？ ・どういう達成目 標を立てるの か？ etc.. 成り 立たせる 主役！ 今日はここのプロセスに着 目してみる
9. 今から話すこと：どういう時に頓挫するのか？／どうしたら良かったか？ モノが 　「うまく機能しなかった」、 　「不安定化した」、 　「陳腐化して、うっちゃられた」 アンチパターンから 正しいヒト、カネの 運用方法を見ていく
10. 方法①：「片手間で」やらない タスクとして明確なアサインを行わないと「忙しいので後回し」になる 事例 ・自動化ツールを買い揃えたのだが、普段の開発やテスト活動が忙しく、 　１本も自動テストを作成しないまま 1年が過ぎた ・初期工数をかけて実装した自動テストが、UIの更新によって半年後にはほとんど陳腐化。 　メンテナンスの手が回らず、自動テストの運用が事実上停止した どう すべき か？ 【業務としてアサインする 　💰👤】 　「自動テストをパスしたコードしかマージしない（開発者がちゃんと 　メンテする責任を持つ）」など、既存の活動と連動していると定着しやすい 【専任の自動化メンバー、チームを設ける　 💰👤】 　・個々のプロジェクトの忙しさに影響されず、計画的な運用ができる 　　お金のかかること！ 後回しにならない、良い運用例
11. 方法②：「都度都度」やらない 「改修箇所」＝「今後も変わる箇所」。自動テストは「枯れた機能」を中心に 事例 ・「各案件で改修内容に合わせた自動テストを実装」としていたら、以下の問題が発生 　　ある案件で実装したテストが、別の案件での改修で動かなくなった 　　短い開発サイクルの中で、自動テストを実装する余裕がそもそもない どう すべき か？ 【システム全体のリグレッションテストとして実装する　 👤】 　・「既存機能が壊れていないか」を、「テストの失敗」に着目してチェック・改修するのが基本 【個々の改修プロジェクトとは独立した体制で実装する　 💰】 　・予算の検討も必要
12. 方法③：適用の仕方、範囲をきっちり見極める アセスメント＆計画をしっかり！「今後誰がやるのか？」も考えて 事例 ・「なんとなく」 範囲を決めてテスト自動化に着手したが、 　「技術的に自動化不可能なテスト」が大量に見つかり、頓挫した ・「とりあえず触れるところから」 テスト自動化を始めたが、 　カバレッジがあがらず、生産性向上に貢献できていない ・「技術者任せで」 テスト自動化を進めていたが、コードが複雑すぎて 　後任メンバーが全くメンテナンスできない ある べき 姿 自動化は手探り厳禁。目的を見据え、可能性を探り、計画的に進める　（💰👤＋α） 【自動化可能性アセスメント】 　・その機能は本当に自動テスト可能か？ 効率は高いか？ そもそも目的にあっているか？　まず見極める 【実装のデザイン】 　・どのステップを共通化するか、データはどう準備するか……など 【運用計画】 　・いつ・どれくらい実行するか、誰がメンテナンスするか（だとすると、実装難易度は適切か）……など
13. うまくいくような進め方 最良の進め方とはどういうものか？ 【さらに】 専任のチームが担うことができれば、活動の最大効率が見込める。
14. もう一つの提言：「そんなこと言われてもねえ」について とはいえ「予算が」「台所事情が」 ……。そんな悩みへのいくつかのヒント パイロット プロジェクトを えらぶ 以下のようなプロジェクトで小規模に導入し、まずシミュレーションしてみる 　・比較的工数に余裕がある、進捗がクリティカルでない 　・小規模で難易度が低い〜中程度 　・他の重要プロジェクトに依存しない スモール スタートで 効果を測る 小さく実装してみて、「拡大した場合の工数削減率はどうか？」を推測する 行けそうなら、徐々に大きくしていく AIも活用する ・AIエージェントを駆使して、人手のかからない自動化を考える ・AIに自動化計画の相談をしてみる
15. 最後に…… 「机上の空論ではないのか？」エンジニアに聞いてみた 逆井 エンジニアさん 技術の担い手の目、現場の目で見ても 実際こうでしょうかねえ 納得感あり。 そもそもテスト自動化は、テストの難しさに加え プログラムの設計や運用の難しさも乗ってくる。片手間のリ ソース、無計画で成功させることは難しい。 AIさん 運用の鉄則を説く主張は適切だが、技術の難しさと SDET（Software Development Engineer in Test）や テストピラミッドの視点を加えると、 より現代的で完璧になる。
16. ありがとうございました