AIでテストプロセスを自動化しよう251113.pdf

WAKE Careerさま勉強会
https://wake-career.connpass.com/event/372588/
コチラでお話させていただいた内容

Transcript

1. AIでテストプロセスを 自動化しよう ＠Test_K_SAK 25’ 11 坂田 一徳 （フリーランス QA）
2. 自己紹介 名前：坂田 一徳（Sakata Kazunori） 職歴：（2025年時点）QA歴 15年 02年 QA▶製造業品証▶薬局向けシステムQA ▶塾教室長▶金属加工▶食品製造▶QA（第三者検証）▶QA（派遣） ▶フリーランス4年目 現在 長野県上田市在住フルリモート渋谷の事業会社に参画中 役員：地元自治会、消防団（元） 住宅ローン残14年、一人息子大学2回生一人暮らし
3. 大前提 今日のスピーカーは 「Hello World」を表示する仕組みが 作れる程度のプログラミング能力です
4. まとめ 開発者のテストは自分の仕事が「正しいらしい」ことを確認する手段 ▶ 安心して次の作業へ 「正しいらしい」ことを確認するために ▶ やみくもなテストをしない AIツールを作ってみての知見 ▶ AIのアウトプットは、普段の自分がそのまま反映される
5. • サイクルの高速化（AIにより更にブーストがかかる） ◦ 失敗Welcome！ ◦ レジリエンス、心理的安全性……etc, ◦ 早く小さく失敗して、改善していくサイクル ▪ プロダクトもFour Keysなど「速さ」が求められる ◦ 「絶対売れるもの」を作る難しさ ▪ DevOps など「速いフィードバック」の必要 ▪ 「フィードバック」の価値が上がっている • テストの価値「フィードバック」 ビジネス潮流の変化（による開発の変化） 速いフィードバックで 安心して次へ進む
6. QAの業務 • QAとして私はどのようなことをしているか ◦ 基本的にE2Eのシステムテスト（動的テスト） ◦ 仕様などのレビュー（静的テスト） ◦ 検出したバグの進路のお世話 ◦ QAプロセス改善 ◦ テスト結果から品質分析（開発向けにバグ修正ペースを提供など） • 目的：開発チームへのフィードバック（評価） ◦ 安心して機能開発を進めてもらう ◦ リリース可否判断の材料提供 ▪ 想定された使い方や特定の要求事項を満たす程度が確保されているか
7. テストを分類してみる 明確 未知 探索的テスト 確認 バグ出し 目的 確実性 技法を使った テスト 妥当性確認 チェック pixiv より
8. 自動化できるテスト 明確 未知 探索的テスト 確認 バグ出し 目的 確実性 技法を使った テスト 妥当性確認 チェック
9. 『チェック』とは（「正しいらしい」ことを確認するスコープ） • 目的 ◦ 仕様通りかどうかの確認行為 ▪ ユニットテスト ▪ インテグレーションテスト ▪ E2E自動テスト（リグレッションなど） ◦ 重要なユーザーストーリーが動くことの確認 ◦ 開発者の安心に繋がるフィードバック • 対象 ◦ A → システム → A ’ となることが決まっている機能 ▪ 入力と期待結果が明確＝テストを書ける
10. 自動テストの課題感あるある • 課題感 ◦ スクリプトを決め打ちした自動テスト ▪ スクリプト作成に時間がかかる ▪ ちょっとした変更ですぐに失敗する ▪ 保守工数が、無視できないくらい膨らむ • 失敗し続ける続けるテスト＝無意味 • 直したいけど工数がないジレンマ ◦ 適切なテスト（行うべき確認）ができているか不明 ▪ 何のためのテストなのか？ ◦ 前提）新しいバグは見つからない ▪ 昨日まで動いていたものが壊れてないかチェック ▪ すぐに結果を得られない（ことが多い）
11. 自動テストの課題感あるある AIと自動テストツールを組み合わせて 「ちょうど良い感じのテスト」で 解決したい！
12. 注意点：テストの型（プロセス）を守ろう 計画 モニタリングとコントロール 完了 分 析 設 計 実 装 実 行 何に対して どうやるか AIに任せると 「無意味なテスト」を量産する
13. 自動テストで行うチェックで必要なこと • オンデマンドな実行 • 素早いフィードバック • なんのためのケースか？を失わない
14. ツールを作ってみた（25’ 6月） 1. サクッと動かす 2. サイトのURLを渡して 3. AI ）実行すべきテストを生成 4. Playwright）テストケースを実行 5. Tool ）実行したケースを分析・修正 6. AI ）テスト結果を分析して残りのテストを探索 7. 手順3へ
15. 伏兵現る！！ 2025年10月 Playwright Agents兄弟が登場 Planner）テストを計画 Generator）テスト生成 Healer）テストを修復 前作を作ってから3ヶ月 ツールでやっていたことがCLIから 簡単にできるように……😢 自作 AI系Toolの寿命の短さを知る
16. テストプロセス全体を自動化しよう テスト計画：どんなテストをしようか テスト分析：何に対してテストするか テスト設計：どうテストするか テスト実装：実際にどうやるか テスト実行：計画に沿ったテストを行う 監視：進捗やカバレッジはどうか AgentsのPlanner AgentsのGenerator Playwright MCP AgentsのHealer
17. Playwright Agents 使ってみての所感 2025年10月 Playwright Agents兄弟が登場 Planner）テストを計画 Generator）テスト生成 Healer）テストを修復 テストが多すぎる 実行カバレッジが低い （30%台で終わる） 素晴らしい！！
18. ツールを作り直してみた（25’ 11月） 1. CLIでサクッと動かす 2. サイトのURLを渡して 3. AI ）実行すべきテストを（それなりに）計画 4. Playwright MCP経由）計画したテストを生成 5. Playwright MCP経由）テストケースを実行 6. Playwright MCP経由）実行したケースを分析・修正 7. AI ）テスト結果を分析して残りのテストを探索 8. Tool ）手順3へ 9. 最終的にレポーティング APIで呼べないため MCPを噛ませて自作
19. 実際に動かしてみます github Repo
20. ハルシネーション対策（AIツールを作った知見） • Planner） ◦ 思考連鎖の方向をガイドする ◦ テスト観点リスト を渡す ▪ 「不要なテスト」を減らす • Generator） ◦ 現実を見せる ▪ DOM解析の結果を渡す ▪ 自己修復に活かす • 動的DOM解析もMCPで対応 システムをテストする時に「どんな切り口で見るか」を記載したもの Zenn『「思いつき」に依存しないテスト 』 どっちに進んで欲しい か「観点リスト」でガイ ド 道がある方向を DOMで示す
21. 冪等性の低さへの対処（AIツールを作った知見） • 同じプロンプトでも、同じアウトプットとは限らない ◦ 結果として、カバレッジが低い ▪ 実行したテストの結果を再度AIに渡す ▪ 未実行のストーリーを計画する • 未実行のスクリプトを生成→実行！ ◦ ループの繰り返しでカバレッジを向上する 「一期一会な生成結 果」を 前提として考える
22. アイデアの実現まで • 日頃から自分の作業を棚卸しできていた ◦ 言語化が完了していた ▪ プロセスのフロー図 ▪ プロセスのWhy・What・How・In / Outputを明確 にしていた いつでも AI に外注できる状態にしておく
23. まとめ（再掲） 開発者のテストは自分の仕事が「正しいらしい」ことを確認する手段 ▶ 安心して次に進むための技術 • 「本当にヤバい問題」のフィードバックを高速化したい 「正しいらしい」ことを効率的・効果的に確認するために ▶ やみくもなテストをしない • テストからどんなフィードバックが欲しいのか AIツールを作ってみての知見 ▶ AIのアウトプットは、普段の自分がそのまま反映される • 日頃からプロセスを言語化しておく
24. おまけ • アイデアがあれば誰でも走り出せる ◦ ノースキルでも動くものは作れる ◦ 　▶ プロとして求められるハードルが上がる • 自分の仕事を分解（言語化）しておくとAIに外注できる ◦ 改善できる点も見えやすくなる • 持っている知見はAIでブーストされる ◦ 知見を貯めればその分、自分へのリターンは大きい ◦ 「勉強すること」の重要性がますます高まる
25. おしまい ＠Test_K_SAK