今日から始められるテスト自動化 〜 基礎知識から生成AI活用まで 〜

2026年3月20日に開催したJaSST Tokyoでの発表資料です。

1. 今日から始められるテスト自動化 〜 基礎知識から生成AI活用まで 〜 JaSST’26 Tokyo C3-1
2. 本資料について 本資料は、2026/3/20に開催されたJaSST’26 Tokyoのセッション C3-1）今日から始められるテスト自動化 〜基礎知識から生成AI活用まで〜 で使用した資料を公開用に一部編集したものです。
3. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
4. 本セッションの概要 目的・ゴール テスト自動化に関して広く全体像を掴み、これからテスト自動化を始める際の第一 歩にする 「聞いたことある」状態 本セッションの主な対象者 ソフトウェアテストの経験があるが、自動化の経験は無い方 手探りで自動化を進めているが、合っているか不安という方 背景 JaSST等でのホットなトピック、興味関心が自動化から生成AI活用に移ったが、基 本的な内容を学ぶ場も必要と考えた
5. 伊藤 由貴 / Yoshiki Ito QAエンジニア・テスト自動化エンジニアとし て10年以上経験。 テスト自動化技術の普及推進チーム立ち上げ や、事業会社でのQAチーム立ち上げを経て 2025年MagicPod入社。 『ソフトウェアテスト技法練習帳』共著。 JSTQBテスト自動化エンジニアシラバス 翻訳メンバー。 MagicPod エバンジェリスト 自己紹介
6. AIが自動テストの作成からメンテナンスまでサポート。 効果的なテスト自動化で、開発全体の効率UPへ。 ノーコードテスト自動化ツール
7. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
8. ISTQB用語集では テスト自動化とは 引用：https://glossary.istqb.org/ja_JP/term/test-automation
9. テスト自動化とは 広義のテスト自動化 テストレベル・テストタイプを問わず何らかのテスト活動を自動化 狭義のテスト自動化 テスト実行の自動化
10. テスト設計 テストプロセスとテスト自動化 引用：ASTERセミナー標準テキスト 一般によく言われる “テスト自動化” 実行以外は技術的に まだこれからですね、 と言っていたが、 2026年現在ではみな チャレンジしている状態
11. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
12. テストの効率性の向上 機能カバレッジの拡大 総テストコストの削減 手動テスト担当者が行えないテストの実施 テスト実行期間の短縮 テスト実行頻度の向上およびテストサイクルに要する時間の短縮 テスト自動化の目的 （JSTQB AL テスト自動化エンジニアシラバスより）
13. より多くのテストをビルドごとに実行可能にする 手動では行えないテストを作成できるようにする（リアルタイム、リモート、並列テスト） 手動より複雑なテストの実行 テスト実行の高速化 オペレーターのミスによるテスト結果への影響を低減 より効果的・効率的にテストリソースを使用する ソフトウェア品質に関するフィードバックの迅速化 システムの信頼性向上（再現性、一貫性など） テストの一貫性の向上 テスト自動化の利点 （JSTQB AL テスト自動化エンジニアシラバスより）
14. 1.プログラムの新しいバージョンで、既存の（回帰）テストを動かす 2.テストをもっと頻繁に、たくさん行う 3.手動では困難または不可能だったテストを行う 4.リソースの有効利用 5.テストの一貫性と再現性 6.テストの再利用 7.市場に早く提供できる 8.自信が持てる テスト自動化の利点 （ 『システムテスト自動化標準ガイド』より）
15. メリットのカテゴリ 詳細 テストの有効性の拡⼤ 長時間にわたる操作や高精度な制御が必要な操作など、⼿動で は困難なテストを実現します。 テストの効率性の改善 ⾃動化によって⼿動のリソースを削減したり、リソースあたり のテスト量を増加させます。 テストの正確性と信頼性の改善 ⼿動操作によるミスや誤差の削減、偽陽性・偽陰性の軽減につ ながります。 テストの保守性の改善 CI （継続的インテグレーション）などに組み込むことで、テス トを実⾏可能状態に維持しやすくなります。 テストの適時性の改善 テスト実⾏によるフィードバックを適切なタイミングで得られ るようにします。 テストの迅速性の改善 テストの実⾏時間を最適化し、全体的な所要時間を短縮しま す。 テスト自動化の効果 （ 『ソフトウェアテスト徹底指南書』より）
16. 開発スキルの獲得 テスト担当者が自動化を通して開発スキルを獲得し、他のテスト活動の効率化につ ながる より高度なテスト分析・テスト設計への注力 単純作業の自動化によりリソースを確保し、高度なタスクに注力できる 開発プロセスの改善 自動化の過程でテスト用意性の確保など開発プロセスの改善が促進される 体制の改善 自動化の過程でテストと開発の組織間連携の仕組み化が促進される テスト技術の強化に立脚したチャレンジの促進 技術蓄積や改善の余力の創出、 「自動化を成功させた」という自信が得られること で次の改善につながる テスト自動化の副次的な効果 （ 『ソフトウェアテスト徹底指南書』より）
17. 参考：テスト自動化のお掃除ロボット効果 お掃除ロボットを買うと部屋が綺麗になる理論 お掃除ロボットが部屋を綺麗にするからではなく、お掃除ロボットを 動かせる状態になるよう人間が片付けをする＆その状態を保つから テスト自動化のお掃除ロボット効果 テストを自動化するために、開発プロセスや組織の様々な課題を解 決・改善した結果、さまざまな状況が良くなること テスト自動化とお掃除ロボット　参照
18. 参考：テスト自動化の無形資産・無形費用 Improved professionalism of test organization テスト組織のモチベーションや生産性を高める Expansion into advanced test issues 能力の拡張 Not all members of the test team will want to change 変化を望まないメンバーもいる The changes in the quality of test 品質が向上する場合もあるし悪化する場合もある 引用：Cost Benefits Analysis of Test Automation (Douglas Hoffman 1999)より一部抜粋
19. テスト自動化の目的や利点のまとめ テスト実行の効率化・高速化 正確性・信頼性の向上 カバレッジやテスト能力の拡大 コスト・リソースの最適化 フィードバックの迅速化・市場投入スピードの向上 組織的効果
20. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
21. 組織でシステムテストを自動化する際の流れ 自動化の 目的を定める ツール等を選択し トライアルや 技術検証 導入 運用へ ※ただしこれらはあくまでも教科書的な流れ。 　実際には異なる流れになる場合もあり、 「この通りでないと絶対にダメ」ではない。 　手戻り等の少ない進め方として覚えておくとよいです。
22. テスト自動化の目的を設定する 目的の目的 組織・チームで共通認識を持ち、手段や方向性がブレるのを防ぐ 目的が明確でないと、過剰な期待をしたり、自動化という手段が適 していない問題に対して自動化で解決しようとしてしまう 効果検証を行う 目的がないと、自動化が進んだ先で効果検証ができない 「なんとなくよさそう」 「なんとなく無駄」
23. As-Is, To-Beから問題と課題を設定 現在の姿 理想の姿 理想と現実のギャップ＝問題 理想と現実のギャップを埋める対策 ＝課題：テスト自動化！ 理想の姿、現在の姿、 そしてそのギャップである問題を 正しく認識できていますか？ 問題に対して、テスト自動化という 手段はほんとうに有効ですか？
24. 組織でシステムテストを自動化する際の流れ 自動化の 目的を定める ツール等を選択し トライアルや 技術検証 導入 運用へ ※ただしこれらはあくまでも教科書的な流れ。 　実際には異なる流れになる場合もあり、 「この通りでないと絶対にダメ」ではない。 　手戻り等の少ない進め方として覚えておくとよいです。
25. ツールの選定や自動化の仕組みの構築 テスト自動化という問題解決の手段を、どのように実現すれば効果的かつ 継続的に行えるかを検討する。 よくある質問：ツールは何を選べばいいですか？ 　　　　　　　→　　　　　　　　　　　　　　です。 ・・・はさておき、ここからは選定に関する主な軸をご紹介。
26. 参考：他のテストレベル・テストタイプでは？ 単体テスト プログラミング言語ごとの標準的なテストフレームワークを使用 テストコードは当然書くもの、という認識の場合も多く、個人やチー ム単位の取り組みとして小さく始めることが多い 結合テスト やりたいテストの内容次第で様々なツールを用いるが、単体テスト・ 結合テストとも無料で使えるライブラリが多い 非機能テスト こちらもテスト毎に有料・無料様々な専用ツールがある
27. 大前提：テスト対象を動かせるものを選ぶ 最初の観点：操作・実行可否 Windowsアプリケーション・Webアプリケーション・モバイルアプリ ケーションあるいはそれらの複合など、自分たちのテスト対象に対応 しているかを見る 機能面に加え、社内ルール等も確認する セキュリティ上の制約が厳しい場合、ツール選定に影響することも
28. 有料 無料 メリット例 サポートがある 学習コスト低 豊富な機能 継続的な機能追加 ライセンス料がかからない サンプルコードや技術ブログなど の情報が多い ツール例 Playwright Selenium Appium Maestro 選定の軸：有料 or 無料
29. ノーコード/ ローコード コーディング メリット例 学習コスト低 誰でも⾃動テストの作成・実⾏・ メンテナンスができる プログラミングや開発のスキルが 高ければ、色々なことができる ツール例 Playwright Selenium Appium Maestro 選定の軸：ノーコード/ローコード or コーディング
30. 選定のおおまかな候補 無料×コーディング 有料× ノーコード/ローコード OR
31. コーディングによる自動化の例 自動化のやり方 画面の操作手順や期待結果との比較をプログラミング言語で記述
32. ノーコードでの自動化の例 自動化のやり方 画面の操作を記録したり、コマンドを画面上で並べることで自動化
33. まずはやってみる 有料ツールのトライアルに申し込む 情報セキュリティ部門や法務部門など各所の許可を得たうえで実施 触り比べて雰囲気を掴んだり、問い合わせの回答の確認なども 有料ツールのハンズオンに申し込む MagicPodでは毎月開催中
34. 組織でシステムテストを自動化する際の流れ 自動化の 目的を定める ツール等を選択し トライアルや 技術検証 導入 運用へ ※ただしこれらはあくまでも教科書的な流れ。 　実際には異なる流れになる場合もあり、 「この通りでないと絶対にダメ」ではない。 　手戻り等の少ない進め方として覚えておくとよいです。
35. テスト自動化ツール導入時のポイント いきなり大量のテストを自動化せず、少しずつ増やす 属人化を防いで、誰でもメンテナンスできる状態を保つ 作成した自動テストを日々実行する
36. 自動テストをいきなり増やさず、スモールスタート テスト自動化の失敗原因の一つが、メンテナンスが追いつかないこと テストの数が多いと、それだけメンテナンスが大変になる 最初は少量から始め、慣れるとともに（自分たちの範囲内で）増やす
37. 参考：hacomonoさま発表より 引用：MagicPodでモバイルアプリの”自動テスト”を最速で立ち上げよう
38. 属人化を防いで、誰でもメンテナンス 特定の人に自動テスト関連の業務が偏ると、異動や退職で止まってしまう SET（Software Engineer in Test）チームなど体制がある場合は別 自動テストの成功は、皆で取り組むかどうかにかかっている 属人化を防ぐための具体的なアクション ペアテスト自動化・モブテスト自動化 実行結果の確認とメンテナンスを、週単位など当番制にする 定例の場で、自動テストの実行状況をシェア 自動テストの結果をSlack等のツールで広く通知
39. 作成したテストを日々実行する 自動テストは、たまにしか実行しないとすぐにメンテナンスできなくなる 腐ってしまう、といった表現をされることも できれば毎日実行し、テスト対象の変更やテスト自体の問題を早期検出 手動ではできない頻度でテストを実行する、のも自動化の利点
40. 参考：サイボウズさま発表より 引用：MagicPodで始めるがんばらない回帰試験の自動化
41. 組織でシステムテストを自動化する際の流れ 自動化の 目的を定める ツール等を選択し トライアルや 技術検証 導入 運用へ ※ただしこれらはあくまでも教科書的な流れ。 　実際には異なる流れになる場合もあり、 「この通りでないと絶対にダメ」ではない。 　手戻り等の少ない進め方として覚えておくとよいです。
42. 組織でシステムテストを自動化する際の流れ 自動化の 目的を定める ツール等を選択し トライアルや 技術検証 導入 運用 ※ただしこれらはあくまでも教科書的な流れ。 　実際には異なる流れになる場合もあり、 「この通りでないと絶対にダメ」ではない。 　手戻り等の少ない進め方として覚えておくとよいです。
44. テスト自動化は運用が大事 「どうやって始めるか」に意識が向き、導入後の運用が見逃されがち 始め方・導入は情報がたくさんあり、ツールもどんどん便利に どんなに便利な道具でも、うまく使えなければ効果が得られない 運用とは？
45. 日々の自動テストの運用サイクル 実行 結果確認 メンテナンス 日次など定期的に実行 特に失敗したテストを確認 バグなのか、テストの問題 なのかを切り分け テストの問題で失敗した ケースについて、正しく 判定ができるように修正
46. 平和な運用サイクル 実行 結果確認 メンテナンス 平日夜間に自動実行 出勤してまずは結果を確認。 数ケースが失敗 原因を切り分け、バグらしき 事象を担当開発者に共有 テストの問題で失敗した ケースをすぐに調整＆成 功確認 朝会で共有し、自分のタ スクに注力 😊
47. 辛い運用サイクル 実行 結果確認 メンテナンス 平日夜間に自動実行 出勤してまずは結果を確認。 たくさんのケースが失敗 原因を調べたところ、ほぼ全 てテスト側の問題 すぐに修正するもなかな か成功せず 手分けをする相手もおら ず、気づいたら1日が自 動テストの修正で終わっ ていた・・・ 😨
48. バグではないのに自動テストが失敗する原因の例 処理速度やタイミング ネットワークやデータ量などで処理が重く、画面表示前に操作が先行 してしまう テストデータや環境 自動テストのたびにデータを消費していて、あるとき枯渇した 画面や状態がテスト実行のたびに変化している 広告やシステム日付など、可変の要素がある
49. 自動テストの失敗が続くと、オオカミ少年化する 自動テストの結果の信頼性が低下し・・・ バグを検知したときに信じてもらえなくなる 「またテスト側の問題でしょ？」 「バグじゃないんでしょ？」 自動テストに取り組む優先度が下がる ツールの契約終了 手動テストへの回帰
50. 参考：Flakyテスト フレイキーテストとは，テストの実行結果が実行するたびに異なる テストである．その原因として，テスト対象の状態やテスト環境の 状態，テストの実行順序などが挙げられる． 不具合の誤検出/見落と しにつながり，テストの信頼性を低下させてしまう．結果，ソフト ウェア開発業務の随所に影響を及ぼすと言われている． 引用：フレイキーテストにどう立ち向かうか[PDF]
51. 自動テストを安定させるには 固定秒数の待機を使わずに「＊＊が表示されるまで待機」を使う 最近のツールは待機に関しても一定自動でやってくれる テストデータの追加や変更手順を考慮する 既にあるデータを消費していくといつか失敗する 実行前にそのテスト用のデータを登録する処理を入れる、一定期間ごとにDBに一 括登録するなどを運用に組み込む 画面上の要素を特定しやすくする 開発者と協力し、アクセシビリティIDを設定するなど そもそもGUIでテストしなくていいものは、しない
52. Point! 単体テスト・結合テストで行えるものはそちらで。 システムテストはシステムテストでしかできない内容に注力。 結合テスト システムテスト 単体テスト コスト高・実行時間長 コスト低・実行時間短 単体テスト 結合テスト システムテスト 参考：テストレベルごとのバランス アイスクリームコーン テストピラミッド
53. 再掲：日々の自動テストの運用サイクル 実行 結果確認 メンテナンス 日次など定期的に実行 特に失敗したテストを確認 バグなのか、テストの問題 なのかを切り分け テストの問題で失敗した ケースについて、正しく 判定ができるように修正
54. 自動テストはメンテナンスが必要 テスト対象に変更が入った場合、それに対応する必要がある 画面上の操作対象やユーザー導線の変更、期待値の変更など 自動化したシステム・E2Eテストは、なぜか「何もしていないのに壊れる」 不安定になる、等も含める 作った自動テストが動き続けて、かつ 適切に（精度高く）リグレッションを検知できる状態をキープ Point!
55. メンテナンスをできるだけ楽にするために 自動テストを上手に作る 先に挙げたような、安定した自動テストになるポイントを実践 （特にE2Eテストを）細かくたくさん作りすぎない 必要に応じてPageObjectPatternなどのデザインパターンを用いる 誰もがメンテナンスできる状態にする こちらも先に挙げた、属人化を避けるポイントを実践 社内やチーム内のナレッジベースを充実させる ツールの力を借りる 自動修復（AutoHeal, SelfHealとも）など、メンテナンスを楽にする機能
56. 日々の自動テストの運用サイクル 実行 結果確認 メンテナンス 日次など定期的に実行 特に失敗したテストを確認 バグなのか、テストの問題 なのかを切り分け テストの問題で失敗した ケースについて、正しく 判定ができるように修正 運用サイクルを 組織で回す！
57. トライアルの際はどんなポイントを見ればいいの？ 実行 結果確認 メンテナンス 既存の開発ツールや開発プロセスに組み込めるか 日々の定期実行ができそうか 自分たちのやりたいテストができそうか テストが安定して動くか 結果は見やすい・わかりや すいか PMやビジネスチームなど広 く関係者に共有できるか メンテナンスはしやすいか 皆がメンテナンスでき るか サポートが充実している、 もしくは自己解決のための 参考情報が豊富か 運用サイクルを 組織で回す！
58. よくある質問：E2Eテスト、どこからやるか E2Eテストは100%自動化をめざすとうまくいかない（ことが多い） どんな順番でどこまでやるか、を考える必要がある 順序・範囲を決める方法はいくつかある 大まかには、なんらかのスコアをつけて上から順にやる方法 次ページから紹介
59. 引用：質とスピード（2022春版、質疑応答用資料付き）P105~111 『リーン開発の現場』のやり方 リスク、手動テストのコスト、自動化コスト、に大小をつけ、 リスクと手動テストのコストが大の部分から実施。
60. 引用：Which Tests Should We Automate? by Angie Jones Angie Jonesのやり方 直感（G） 、リスク（R） 、価値（V） 、費用対効果（C） 、過去の状況（H）で スコアを付け、自動化対象を選択する方法
61. 引用：テスト設計チュートリアル_テスコン編25 テストコンテナから考える テストコンテナモデルを用いてテストの全体像を表現したうえで、 「ここを自動化」と決める。 いずれの方法も、 チームで優先順位・ 範囲を考え、 合意することが大事！
62. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
63. 再掲：組織でシステムテストを自動化する際の流れ 自動化の 目的を定める ツール等を選択し トライアルや 技術検証 導入 運用へ ※ただしこれらはあくまでも教科書的な流れ。 　実際には異なる流れになる場合もあり、 「この通りでないと絶対にダメ」ではない。 　手戻り等の少ない進め方として覚えておくとよいです。
64. 組織で始める“前”に個人でできること たまに目にするつぶやき：現場で自動化したいのにGOが出ない！ 組織で導入に向けて動けない場合は、個人でスキルを身につける必要がある 「私はできるので、やらせてください！」と交渉 自動化ができるところへ移る 完全にプライベートでやる場合：書籍やWebサイトを参考にやってみる
65. 個人で始める場合、具体的に何をすればよいか Web・モバイル・デスクトップのうち自分が仕事で扱っているものを自動化 無料のツールからまずは触ってみる このとき、必ずしも独力でマスターする必要はなく、感覚を掴むことが大事 難しさや大変さ、つまずきやすいポイントを体感することも価値 触ってみてわかったことを含めてアウトプット 技術ブログ 社内Wiki等ナレッジベース 自分で「テスト自動化入門研修」を作って社内で開催する
66. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
67. ソフトウェアテストにおける生成AIの活用 テストプロセス中の各段階において、生成AI活用が検討・実践されている。 テスト計画 テスト分析 テスト設計 テスト実装 テスト実行 テスト完了 テストのモニタリングとコントロール
68. テスト自動化における生成AI活用：テストコード生成 テスト仕様書 / 設計書 / ソースコード 「こんなテストがしたい」という指示 など 自動テストコード
69. （現在の）テストコード生成の注意・懸念点 たくさんのテストが生成できてしまう メンテナンスの手間が増大しやすい テスト内容の詳細について理解しづらい テスト内容の変更をどう反映するか問題 都度生成 作成したテストコードを人間（とAI）が編集する 結局、一定のスキルが求められる など
70. 参考：MagicPod Autopilot チャットから言葉で指示を出すことでテストの作成や修正が可能。
71. MagicPodにおける、その他の生成AI活用例 AIアサーション テスト概要の要約 失敗原因分析エージェント
72. AIアサーション 機能概要 実装済みの機能 画面に表示されているものが妥当か生成AIでチェック 普通の確認コマンドや画像差分チェックでは難しい場面で利用 利用例 検索キーワードと検索結果の整合性 デザイン崩れ・画像読み込みエラーなどの全体的なチェック
73. 失敗原因分析エージェント テストが失敗した場合に、AIが原因を調査・分析 テストケースをどのように修正すればよいか、具体的なアクションも提示 実装予定の機能
74. 目次 1. はじめに 2. テスト自動化とは 3. 目的・効果 4. テスト自動化を組織で始める 5. テスト自動化を個人で始める 6. 生成AIの活用 7. まとめ
75. まとめ 個人でテスト自動化を始める 「とりあえずやってみる」でOK 大事なのはうまくやるよりも、どう便利でどう大変かの感覚を掴むこと その先に繋げたければ、アウトプットが大事 組織でテスト自動化を始める 目的を定め、トライアルをし、導入する 運用が大事
76. Appendix
77. テスト自動化のROI、よくある（しかし危険な）計算 手動テストと自動テストの累計コストをグラフ化して、損益分岐点を見積もるという考え方。 手動 自動 実行回数 累計コスト 「N回やれば もとがとれる」
78. コスト削減を主目的とするのが危険な理由 過剰な期待をしてしまう テスト工数は（特に短期的には）思ったより減らないこともある 本来必要なコストが見逃された状態で試算→想定ROIを下回る 得られるはずの効果を見逃してしまう 不具合や障害等の対応コストの低減など Point! コスト削減できる場合もあるが、主目的にすると 判断を誤ることもある
79. 品質コストの概念 各コストの説明はフィリップ B・クロスビー著/小林宏治監訳『クオリティ・マネジメント　よい品質をタダで手に入れる法』 より 予防コスト “製品のデザインと開発における欠陥を防ぐ、すべての活動のコスト” 評価コスト “ハードウェア、ソフトウェア、サービスが、要求条件に合致しているかどう かを決定するための検査、テストおよび評価を行うのに要するコスト” 失敗コスト “製品が要求条件に一致しないために、いろいろな事柄に関連して 発生するもの”
80. MagicPodのご紹介 Appendix
81. AIが自動テストの作成からメンテナンスまでサポート。 効果的なテスト自動化で、開発全体の効率UPへ。 ノーコードテスト自動化ツール
82. AIの技術を活用したテスト自動化サービス 豊富な機能と高いメンテナンス性でリリースサイクルの高速化を支援します ノーコードでテスト作成が可能 読みやすい自動テストが誰でも作成できる モバイルアプリ + ブラウザ テスト ユーザー数・テスト実行回数無制限 MagicPodとは
83. 特徴：ノーコードでテスト自動化が可能 テストステップを作成 テスト結果と結果詳細画面への導線 画面上から テスト対象要素を選択 要素自動検出を開始 2 3 4 1
84. MagicPod Autopilot ユーザーの指示に基づき、テスト を自動で作成します。既存テストの 修正などにも幅広く対応します。 画面の内容やテキストを理解し、 従来は人間が検証する必要があっ たテスト項目も自動化します。 UIに変更があった場合に、AIが テストケース側の修正を提案・修 復します。 AIアサーション AI自動修復 テスト作成 テスト結果確認 テストメンテナンス MagicPodは、テスト作成のMagicPod Autopilot、結果確認のAIアサーション、 メンテナンスのAI自動修復の3つの機能を搭載しました。 テスト作成・確認・運用の3つをAIがトータルサポート
85. Autopilotのチャットから指示を出します。 Autopilotのチャット形式の入力欄に「＊＊＊を行うテストを作成して」などの指示を 出すことで、Autopilotが自動で適切なテストを検討・作成し実行します。 テスト作成：MagicPod Autopilot
86. 「AIで確認」コマンドは画面の情報をAIが読み取って、意味を理解した上で検証します。 これまでは人間による目視確認が必要だったテスト項目も、自動化できるようになりました。 1 2 3 検索欄に「東京都千代田区」と入力 検索ボタンをクリック 検索結果画面で「千代田区に位置アイコン が表示されているか」を AIで確認 千代田区にアイコンが 表示されています OK! OK! OK! 千代田区 テスト結果確認：AIアサーション
87. テスト対象アプリケーションに変更等があると、そのままではテストは失敗してしまいます。 MagicPodのAIはテストを自動で修復して実行を継続。実行後に修正案を提案します。 自動修復が働くと「要確認」 　　と表示されます ! テストメンテナンス：AI自動修復
88. ユーザー 登録 無料 トライアル お支払い・ ご利用開始 https://magicpod.com/consulting 導入にあたってのご相談・Q&A ご利用までの流れ