ソフトウェアテストのAI活用_ver1.10

Transcript

1. ソフトウェアテストの AI活用 猫おじさんの PoC実験結果 (2025/5 Ver1.10)
2. PoCにおける目的 私のAIを活用した PoCの目的を以下へ列挙しておきます。 　・　自分の意思をAIに伝えた上で、どこまでAIが対応できるのか？ 　・　どこまでAPI実装によりテスト工程の自動化を実現できるのか？ 　　 (できること、できないこと、前提条件、 　　　他の方が同様に再現させる上で課題となることは何か？) 　・　作ってみた結果の精度はどうなのか？
3. 更新履歴 No Ver 内容 担当 日付 1 1.00 初版発行 fumi.kato 2025/4/27 2 1.10 タイトルを変更 更新履歴を追加 以下を補足資料へ移動 　　- テスト計画書について 　　- テスト設計書について 　　- レビューについて 　　- テストケースについて 　　- テストスクリプトについて 　　- テスト実行について 　　- テスト報告書について fumi.kato 2025/6/1 Ver1.10更新ページ
4. 最初にお伝えしたいこと ・ 全体的に人の作業は支援できるが、 AIで全て「0 -> 100」を実現には至らない。 　 全量のAIで行うにはまだ遠いものの 　 1年前と比較すると飛躍的にできることのバリエーションが増えた。 　　LLMの台頭によりこれまでのテスト実行自動化を除き、 　　現時点で「0 ->100」を完全実現できたのはテスト結果報告書のみ 　　＊企業文化によっては、実現できないかもしれないが、最も「 0 ->100」に近い認識 ・ AI活用をイチから進めるには、相応の時間 /コストが必要 　　夢をみず、現実的にできることから着手する方が望ましい 　　実験的なPoCも非常に時間が掛かるので、今回はその見解も踏まえている。 ・ AIが出力されたものはレビューに時間が掛かり、一意に出力されない 　　デメリットとして認識しておくこと。むしろ、活用するならその覚悟が必要。 　　当たり前として認識し、周りにも周知しておく方が良い。
5. はじめに ・　AIを活用したソフトウェアテストに関するドキュメントとして記載しています。 　「2025年5月」時点の更新版となります。 ・　以下については、あらかじめご了承ください。 　　‐　あくまで実用してみた結果などを踏まえている為、 　　　 ベストプラクティスはご自身の企業およびプロジェクトによって異なります 　　‐　新しい生成AIモデル、アプリ層のサービスが提供された場合、 　　　 これらの記載されている前提が大きく変化する可能性があります 　　‐　モデル等の所感はあくまで個人の所感です。 　　　 個人個人に見合った最適なモデルを見つけて頂くことをお勧めします - 今回、API利用についてはOpenAIのモデルをサンプリングしています。 　　　 他のモデルと性能変化がある点についてはご承知おきください - 単体テストにおける活用は様々な記事が出ている為、そちらをご参照ください
6. 生成AIを活用する上で意識すべき点 　AIを日々利用し続ける事のメリット 　　　- 毎日会話することで AIの苦手な点、得意な点を理解できるようになります。 　　　　　以下のような整理が個人でも出来るようになります（あくまで個人の感想です） 　　　　 　　　- 利用に慣れると、他の Closedモデルとの差異が理解できるようになり、 　　　 使い分けがクリアに行えるようになります。 　　　- モデルの特性を知ることで、ハルシネーションのポイントも 　　　 理解できるようになってきます。 　　　　Gemini2.5　…コンテキスト数が多く、 ZeroShotは得意だが、 　　　　　　　　　　　ソースコード記述は得意ではない（できないわけではない） 　　　　　　　　　　　コンテキストの軌道修正がしづらい。 　ChatGPT o1 Pro　…コンテキスト数は少ないが、エラーが発生しない 　　　　　　　　　　　 無難なソースコードを記載をすることが多い
7. 生成AIを活用する上で意識すべき点 　AIへの指示と考えさせることは別の概念 ‐ 指示と考えさせることは別の概念として扱ってください。 例）指示する　　　　　　　　「テストケースを作成してください」 例）考えさせてから答えさせる「この不具合の原因は何でしょうか？」 　　　　*Chain-of-Thought Prompting Elicits Reasoning in Large Language Models https://arxiv.org/pdf/2201.11903 「指示する」と「考えさせてから答えさせる 」はプロンプトの性能ギャップが 　　　　　あることを理解しておいてください。 構造化について 　　　　・AIの回答を構造化しないと意図した回答を得られないケースがあります。 　　　　　モーダル/APIを問わずにプロンプトを構造化させる必要があります。 　　　　　＊APIではJSON Schemeが良く使われますね 　　　　 *QUANTIFYING LANGUAGE MODELS’ SENSITIVITY TO SPURIOUS FEATURES IN PROMPT DESIGN or: How I learned to start worrying about prompt formattinghttps://arxiv.org/pdf/2310.11324
8. 生成AIを活用する上で意識すべき点 　IDEのルール設定、sysytemプロンプトとhuman(user)プロンプト 　　- IDEのルール＆MDC設定： コード品質・一貫性を機械的に担保する（静的解析・整形・リントなど） コード整形ルール、型チェック設定 　　- system prompt　　　 ： LLM の“人格”・振る舞い・制約を規定し、会話全体を統制する 会話全体のフォーマットを絶対に守らせたい場合に利用 　　- human (user) prompt ： ユーザが実際にやらせたいタスク・質問を記述。その瞬間だけ必要な指示
9. AIを活用してテスト設計を支援
10. AIを活用してテスト設計を支援 以下をポイントに解説を進めていきます。 　・　テスト設計の構築（仕様書の整理 =JSON化） 　・　JSONから自然言語のテスト要件 /テスト条件の生成 　最初にお伝えしておきますが、モデル名を除き、 　　「1行もソースコードを記載せずに Vibe Codingで実装」しています。　　よっ て、AIを使えば、誰でも実装できる可能性 があります。
11. AIを活用してテスト設計を支援（準備物一覧） 以下はPoCにあたっての準備したもの 　・　開発IDE環境（CursorのProを利用すると便利かも） 　・　生成AIのAPIの発行（APIは gpt 4.1-miniを利用） 　・　画面仕様、機能仕様、非機能仕様、業務フロー　などを 　　 あらかじめ、Markdown化しておく ・　ソースコード実装で活用するAI（Gemini 2.5 Proを利用） 　・　APIで利用するマネー（7500〜1万円ぐらい利用した） 　・　やりきる心と諦めないメンタル（ここが一番重要）
12. AIを活用してテスト設計を支援（処理順序） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 Markdown仕様書群の解析 機能/画面/ワークフロー/非機能に分類 ID参照・自然言語関連付け 各種convert処理 Mermaid解析・ステップ抽出 JSON統合・出力 テスト要件・テスト条件・図表を出力 以下が処理順となります。 JSON出力までは AIは未使用です。 1 2 3 4 5 6 7
13. AIを活用してテスト設計を支援（処理の一部について） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 ChunkStore ： 解析したMarkdownのチャンクをメモリ上に保持 し、IDによるアクセスや関連チャンクの取得機能 を提供。処理のセッション内でのキャッシュデータ として保持。 マッピング： 一度解析した機能IDと関連画面情報のマッピング をキャッシュで保持。 ベクトル検索： 仕様書チャンクのテキストからベクトル埋め込みを 生成し、ChromaDBに格納。 「1」〜「5」で活用しているキャッシュ処理について記載 1 2 3 4 5 6 7 キャッシュ以外にも並列処理/リトライ処理などはありますが、 よしなにAIが生成してくれるだろうと思うので解説は割愛。 指定しないとやってくれなさそうな処理のみ記載しています。
14. AIを活用してテスト設計を支援（処理の一部について） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 自動ID生成: FUNC-001_IP01, FUNC-001_IP02 のように一意 IDを自動付与 構造化抽出: Markdownテーブルから structured_items として配 列データ化 関係性推論: ファイル名や内容から機能 -画面-ワークフローの関 連性を検出 メタデータ保持: 元ファイルパスや行番号などトレーサビリティ情報を 維持 「6」を生成するにあたり行っている処理 1 2 3 4 5 6 7
15. 仕様書のMarkdownからJSONへの変換例 --- id: FUNC-001 name: ユーザーログイン機能 --- # ユーザーログイン機能 ## 概要 ### 説明 ユーザーがシステムにログインするための認証機能 ### 目的 - セキュアなアクセス制御 - セッション管理による状態保持 ## 入力パラメータ | パラメータ名 | データ型 | 必須 | 説明 | |-------------|---------|------|------| | email | String | ◦ | メールアドレス | | password | String | ◦ | パスワード | ## 事前条件 - ユーザーアカウントが存在する - ブラウザが起動している ## 事後条件 - ユーザーがログイン状態になる - セッションIDが発行される { "id": "FUNC-001", "name": "ユーザーログイン機能 ", "path": "./specs/functions/func_001_login.md", "summary": "ユーザーがシステムにログインするための認証機能 ", "overview": { "description": "ユーザーがシステムにログインするための認証機能 ", "purpose": [ "セキュアなアクセス制御 ", "セッション管理による状態保持 " ] }, "preConditions": [ "ユーザーアカウントが存在する ", "ブラウザが起動している " ], "postConditions": [ "ユーザーがログイン状態になる ", "セッションIDが発行される " ], "inputParameters": [ { "id": "FUNC-001_IP01", "name": "email", "dataType": "String", "required": true, "description": "メールアドレス ", "source": "UI" },
16. AIを活用してテスト設計を支援（処理の一部について） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 JSONからテスト設計を作成する処理は以下。 ステップ1: テスト要件(上位テスト要件)生成 ステップ2: テスト条件(詳細インサイト)生成 ステップ3: 関連性構築 各詳細インサイトと上位テスト要件の IDリンク ステップ4: Markdown構造化 上位要件 → 詳細インサイト (タイプ別) 「7」で行っている処理について記載 1 2 3 4 5 6 7
17. JSONからテスト設計書への変換例 { "id": "FUNC-001", "name": "ユーザーログイン機能 ", "overview": { "description": "メールアドレスとパスワードによる認証 ", "purpose": ["セキュアなアクセス制御 "] }, "inputParameters": [ { "id": "FUNC-001_IP01", "name": "email", "dataType": "String", "required": true, "description": "メールアドレス " } ], "preConditions": [ "ユーザーアカウントが存在する " ], "postConditions": [ "ユーザーがログイン状態になる " ] } ## Function ID: FUNC-001 (ユーザーログイン機能 ) ### 上位テスト要件 (High-Level Test Requirements) - **HRQ-FUNC001-ACCURACY**: ログイン機能は正確な認証判定を行うべき である - *検証フォーカス *: 認証ロジック , 入力バリデーション - *受入基準ヒント *: 有効な認証情報で成功、無効な場合は失敗 - *優先度 *: 高 - *関連する詳細インサイト ID*: FUNCFUNC001VALI001, FUNCFUNC001INVA002 ### 詳細テストインサイト /条件 (関連インサイト ) #### インサイトタイプ : StrategicTestGoal - **STRAFUNC001001** (functionalSpecifications.id=FUNC-001.overview.StrategicTestGoal): この機能 がビジネス要件を満たすための測定可能な品質目標として、認証精度 99%以上 を達成すべきである - *関連上位要件 ID*: HRQ-FUNC001-ACCURACY - *期待/根拠*: 正当なユーザーの円滑なアクセスとセキュリティ確保の両立 - *優先度 *: 高 - *テスト技法 *: 認証テスト , 負荷テスト #### インサイトタイプ : ValidInputCase - **FUNCFUNC001VALI001** (functionalSpecifications.id=FUNC-001.inputParameters[0]_FUNC-001_IP01.Va lidInputCase): 有効なメールアドレス形式での正常認証フローを検証する - *関連上位要件 ID*: HRQ-FUNC001-ACCURACY - *期待/根拠*: user@example.com等の標準的なメール形式での認証成功 - *テストデータ *: 有効メールアドレスパターン一覧 - *タグ*: functional, authentication, email_validation
18. コード実行時のテスト設計書 (Markdown形式)への変換例 {// 各機能・ユースケースごとに実行 async function generate_functional_test_artifacts() { // 1. 詳細インサイト生成 detailed_requirements = await gather([ analyze_conditions(), analyze_input_parameters(), extract_strategic_overview_insights(), ... ]); // 2. 図生成 diagrams = []; // テストレベル・スコープ図 if (diagram_scope = await generate_test_level_scope_diagram( func_id, "function", func_spec_summary, all_reqs_for_diagram)) { diagrams.push(diagram_scope); } // リスクベース戦略図 risk_related_insights = filter_risk_insights(all_reqs_for_diagram); if (diagram_risk = await generate_risk_strategy_diagram( func_id, "function", func_spec_summary, risk_related_insights)) { diagrams.push(diagram_risk); } return [detailed_requirements, diagrams]; } ## テストアーキテクチャ概念図 ### テストレベルとスコープ図 (TestLevelsAndScope) (関連: FUNC-001) **図の解説:** この図は機能FUNC-001（ユーザーログイン機能）における推奨テストレベルと各 レベルでカバーすべきコンポーネントの関係を示しています。 ```mermaid graph TD A[ユーザーログイン機能] --> B[認証API] A --> C[セッション管理] B --> D[ユーザーDB] UT1[単体テスト] -.-> B IT1[結合テスト] -.-> A ST1[システムテスト] -.-> E[E2Eシナリオ] CT1[コンプライアンステスト] -.-> F[個人情報保護] style B fill:#ffcccc style F fill:#ffffcc ```
19. (例）機能仕様から生成されるテスト条件 (詳細インサイト ) セキュリティ・コンプライアンス SecurityConsideration 内容: 入力に関連するセキュリティリスクと検証 出力例: 「SQLインジェクション攻撃への脆弱性検証」 ComplianceCheck 内容: 法規制・業界標準への準拠確認 出力例: 「個人情報保護法に基づく同意取得メカニズムの確認」 出力検証・条件確認 OutputVerificationPoint 内容: 出力内容の正確性検証 出力例: 「認証成功時のセッション ID生成形式確認」 PreConditionValidationPoint 内容: 事前条件の検証ポイント 出力例: 「ユーザーアカウントの事前存在確認」 PostConditionVerificationPoint 内容: 事後条件の確認ポイント 出力例: 「ログイン状態への適切な状態遷移確認」 戦略的テスト観点 StrategicTestGoal 内容: 機能の成功を測定する具体的なテストゴール 出力例: 「認証精度99%以上を達成すべきである」 KeyRiskArea 内容: 最も影響の大きいリスク領域の特定 出力例: 「不正アクセスによるデータ漏洩リスク」 CoreTestStrategy 内容: 主要なテスト戦略の柱 出力例: 「多層防御によるセキュリティ検証重視」
20. (例）機能仕様から生成されるテスト条件 (詳細インサイト ) 入力パラメータ検証 ValidInputCase 内容: 正常系の代表的なテストケース 出力例: 「user@example.com等の標準メール形式での認証成功検証」 InvalidInputCase 内容: 異常系のテストケースと期待される動作 出力例: 「無効メール形式入力時の適切なエラーメッセージ表示」 BoundaryValueAnalysis 内容: 境界値条件のテストケース 出力例: 「パスワード長8文字未満・65文字超過での挙動確認」 DataCombination 内容: 複数パラメータの組み合わせテスト 出力例: 「メール＋パスワードの有効・無効の全組み合わせ検証」 その他 ExploratoryTestCharter 内容: 探索的テストのチャーター 出力例: 「非典型的な認証シーケンスでの隠れた脆弱性探索」 SpecificationFeedback 内容: 仕様書の改善提案 出力例: 「エラーコード定義の曖昧さ解消が必要」 NFRTestAspect 内容: 非機能要件テスト観点 出力例: 「同時ログイン1000件での応答性能確認」
21. テスト設計作成サンプル (1)
22. テスト設計作成サンプル (2)
23. テスト設計作成サンプル (3)
24. AI活用によるテスト設計の考察 初期ドラフト作成の効率化はできそう : 人間が数日～数週間を要する可能性のある多岐にわたるテスト要件群、戦略図、関連表の草案を、約 30分で生成できた。 これを手作業で同様の粒度と網羅性で作成するのは非常に時間がかかる ...IDEのチャットを利用するよりも高速で対応できそう。 観点の体系的網羅 : 定義された多様な観点を、仕様の各要素（機能、 UI要素、ユースケース）に機械的かつ体系的に適用できた。 人間では見落としがちな組み合わせや特定の専門知識が必要な観点からのテストアイデアを系統的に洗い出すことができそう。 トレーサビリティの手間を削減 : テスト要件とテスト条件間の関連付けを行うことで、テストの目的（何を検証するのか）とその手段（具体的にどう検証するのか）を 明確に結びつけることができる。これにより、手作業での関連付けの手間を大幅に削減できそう。 議論の叩き台としては有効だと感じた : 生成された具体的なテスト要件、 Mermaid形式の戦略図（テストレベル・スコープ図、リスクベース戦略図）、そしてドメイン特化型のリスク・テ スト関連表は、チーム内で議論の「叩き台」として非常に有効だと考える。 リスクベースアプローチに使えるかも : 「リスク・テスト関連表」では、ドメインにおける一般的なリスク、それに対応するテストタイプ、さらには使用するテスト技法が体系的に整理でき る。また、Mermaid図においてもリスクの高いコンポーネントが強調表示させることができ、リスクベースドアプローチも利用できそう。
25. AI活用によるテスト設計の考察 項目 人による作業 AIによる共同作業 仕様整理 設計者が熟読し手動整理。解釈にばらつき、大規模では膨 大な時間。 Markdownパーサー等が仕様を構造化・関連付け。初期理解・整理の 効率化、網羅性向上。 テスト要件定義 設計者の経験・知識に依存。網羅性・多様性はテスト設計者 のスキル次第。 構造化仕様に基づき LLMが多角的にテストインサイトを生成。アイデ ア出し効率化、多様な観点の網羅性向上。 テスト アーキテクチャ設計 戦略、レベル、スコープ、リスク分析、図表作成を手作業で 作成。 LLMが概念図や関連表を自動生成。戦略の可視化、共通認識醸成を 促進。 網羅性と一貫性 人間の注意力・スキルに依存。大規模では変更追跡や一貫 性維持が困難。 機械処理とAI分析で抜け漏れリスク低減。中間成果物を介し一貫性 向上。AIの解釈限界は考慮要。 効率とスピード 時間のかかる反復作業が多い。仕様変更対応も時間とコス ト。 自動化・半自動化で大幅な時間短縮・コスト削減。仕様変更にもある 程度追随可能。 成果物の品質 設計者のスキル・経験・コンディション (集中力が...)に左 右。レビューが重要。 入力仕様・プロンプト・ LLM性能に依存。AI生成物は専門家のレ ビュー・修正が不可欠。 人による作業と簡易的に比較
26. まとめ 　・　AIの成果物についてのレビューは引き続き必要 　　　　　＊相変わらず、出力されるテスト技法の名称が適当 (プロンプトで解決できるかな ..). 　　　　　＊昔に比べたらモデルが賢くなったのでレビュー指摘は減っている気が ...(気のせい？） 　・　決まったタスクであれば、 API処理の方がよさそう 　・　モデルが賢くなれば、更にインサイトを得られる出力ができそう 　・　自動化が Mustかと言われると、そうではないと考えるが 　　 圧倒的に初稿が楽なのは間違いない 　　　　　＊流石にレビューするにあたって全然こちらが汲み取れない内容までは出てこない 　　　　　　テスト技法の選定で適当な名前があったとしても、なんとなくやりたいことはわかる 　　　　　＊レビューに時間が掛かったとしても、恩恵はありそう
27. 補足資料 2025/4(Ver1.00)の記載内容
28. 補足資料 　　- テスト計画書について 　　- テスト設計書について 　　- レビューについて 　　- テストケースについて 　　- テストスクリプトについて 　　- テスト実行について 　　- テスト報告書について
29. 参考資料(IDEルールのトークン注入 ) ルールタイプ トークン注入状況 トークン 消費有無 消費条件 (モデルに送られるタイミング ) User Rule (グローバル) 常時 常に消費 Cursor を起動して AI を呼び出すすべてのリ クエストで本文が先頭に挿入 Project Rule – Always 常時 常に消費 .mdc が type: Always の場合、呼び出しごと に必ず先頭へ注入 Project Rule – AutoAttached 条件付き (ファイル一致) 条件付き 現在のチャットや ⌘K 操作で glob パターンに 一致するファイルが話題に上がったときだけ 注入 Project Rule – AgentRequested 条件付き (AI 判断) 条件付き ルールに description があり、エージェントが 必要と判断した場合のみ 注入 Project Rule – Manual 手動 条件付き チャット中に @ruleName を明示した直後の 呼び出しから注入 .cursorrules (Legacy) 常時 常に消費 ルート直下 .cursorrules が存在すると、すべ てのリクエストで全文注入（非推奨）
30. テスト計画書について 💡 テスト計画書を作成するにあたり、いくつか決めることがあります。 　　‐ テスト計画書の作成元とする資料のファイルフォーマット 　　 ‐ 作成時の出力方法（可読性の意味で markdownを推奨） モーダル 人の作業を支援するといった位置づけが主になります。 ‐ IDEのモーダル作成であれば、自動でドキュメントに入力できるため、 コピー作業などの雑務的な手間がなくなりますが、出力量が少ないです。 出力量の参考： 1000行のプロジェクト計画書サンプル（ markdown）を 　　　　　　　基にテスト計画書を依頼した場合 (ゼロショットの記載依頼 ) 　　　　　　Gemini2.5かつcursor利用 ：約250行 　　　　　　Claude3.7sonetかつWebモーダル利用：約400行 　　　　　　o1ProかつWebモーダル利用 ：約270行
31. テスト計画書について API利用 ‐ AIを利用すれば、かなり時短で実装自体に時間はかからないですが、 内容の精度を上げるためのプロンプト調整に時間が掛かります。 　また、図などを Mermaid形式で指定した場合、図が思った形で 出力されないことが多いです（ 1/4ぐらいの確率で成功する程度） ‐ こちらも人の作業を支援する位置づけとはなりますが、 モーダルよりも精度を上げることが可能です。 ‐ Mermaid形式で出力を検討している場合、表の箇所のみ HTMLにすることで、 表の崩れを抑えることは可能です。 　ただし、問題点として、 Markdownの改変がしづらくなる可能性があります。 ‐ 筆者はLangchainを利用して実装しています。
32. テスト計画書について ノートブック型 ダイアログ利用 ‐ 一部作成はできるがテスト戦略なり、テスト方針のたたき台には利用可能です。 　ただし、言葉は同じで意味が異なるものを取り扱う場合は注意してください。 根拠についてもエビデンスはあるが、抽象度が高すぎるような指定の場合、 　出力されない（回答を拒否される）ため、注意が必要です。 💡 AIを活用することで、テスト計画書を作成するメリット 　　‐ イントロダクションを考えてくれる（冒頭の記載を考えるが面倒） 　　 ‐ とりあえず、APIを利用すると自分が記述すべき分量が圧倒的に減る 💡 AIを活用することで、テスト計画書を作成するデメリット 　　‐ テスト計画書における各章の説明準備工数は必要 　　　（記載しなくても書いてもらえるが、記載しておく方が望ましい） 　　 - APIをコーディングする場合、プロンプトの微調整が必要
33. テスト設計書について 💡 テスト設計書を作成するにあたり、いくつか決めることがあります。 　　 ‐ テスト計画書、要件定義などの作成元とする資料のファイルフォーマット 　　 ‐ 作成時の出力方法（可読性の意味で markdownを推奨） モーダル 人の作業を支援するといった位置づけが主になります。 ‐ IDEのモーダル作成であれば、自動でドキュメントに入力できるため、 コピー作業などの雑務的な手間がなくなりますが、出力量が少ないです。 💡参考： 　 表形式で出力がテスト計画書より多くなる為、安価なモデルは避けて 　 表形式を崩さずに出力できる高価なモデルを利用することをお勧めします 　 読み込ませるファイル数が多い場合、 Gemini2.5などのコンテキスト量が 　 多いモデルの利用を検討してください。
34. テスト設計書について API利用 ‐ こちらも人の作業を支援する位置づけとはなりますが、 モーダルよりも精度を上げることが可能です ‐ 実装自体に時間はかからないですが、内容の精度を上げるための 　プロンプト調整に時間が掛かります ‐ どうしてもテスト観点を加えたい場合、 Geminiは理解できるケースが 　ありながらも、 ISO/IEC25010ベース、 AIが理解しやすい形になどする方が 　望ましいです。ポイントは AIが理解できないものを入れないことです。 - AIの回答履歴を要約して履歴をトークンに含めつつ AIに回答させる必要が 　あるため、トークンのキャッシュ、メモリ管理が必要となる場合があります。 ‐ 筆者はLangchainを利用して実装しています
35. テスト設計書について ノートブック型 ダイアログ利用 ‐ 一部作成はできます。 インフラなどを鑑みたテスト環境など、たたき台としては有用です。 　表形式で出力するものなどは非常に見づらくなる点は注意が必要です。 機能毎の詳細な出力を行うように指示することが必要です。 💡 AIを活用することで、テスト設計書を作成するメリット 　　‐ イントロダクションを考えてくれる（冒頭の記載を考えるが面倒） 　　 ‐ とりあえず、APIを利用すると自分が記述すべき分量が圧倒的に減る 💡 AIを活用することで、テスト設計書を作成するデメリット 　　‐ 記載にあたっての抽象化レベルのコントロールが必要 　　 - 記載内容が細かい場合はトークン管理が必要
36. レビューについて 💡 レビューを行うにあたり、いくつか決めることがあります。 　　 ‐ レビュー対象元の収集 　　 ‐ 出力方法の検討（可読性の意味で markdownを推奨） モーダル 人の作業を支援するといった位置づけが主になります。 ‐ 画像、文章などいずれかをレビューのインプット対象とするが、 　レビューを行う為のガイドラインなどは事前に準備を行い、ガイドラインを 　含めたレビューを行うことで、一貫性があるレビューを行うことができます。 💡参考： 　 レビュー報告用のフォーマットを事前に用意して結果を出力できる形に 　 しておくとスムーズな出力ができ、統一感がある形となります。 　 レビュー対象のファイル数が多い場合、 Gemini2.5などのコンテキスト量が 　 多いモデルの利用を検討してください。
37. レビューについて API利用 ‐ レビューガイドラインをプロンプトに入れて、具体例を出した上で 　指摘を行う方が高い効果を得られやすいです。 　＊具体例がない状態でレビューを行うと、プロジェクトの状況を把握していない 　　指摘が挙がってくるので注意が必要です。 　　（例：手動テスト前提だが、テスト自動化の管理方法がない　など） ‐ 通常APIでは安価なモデルを利用するのが一般的ですが、 　安価なモデルでは複雑な思考に耐えられない為、安価なモデル以外の 　利用をお勧めします。 ‐ 思考を追うような段階的なレビューを順次行う方が AI側で思考の整理が 　行いやすいので、多段的なステップを踏ませるようなレビューの方が良いです - レビューを行った内容に対して、さらにループ処理を行うと 　レビュー精度があがります。 　（指摘も増える傾向にあるが、意味的重複削除処理は必要）
38. レビューについて ノートブック型 ダイアログ利用 ‐ レビューはできるものの、包括的なレビューを行うには不向きです。 　ただ、ピンポイントレビューには一定の有効性はあるため、 　範囲を絞り込んだ形で簡易レビューには利用できます。 💡 AIを活用することで、レビューを行うメリット 　　‐ 自身のレビューのプラス αとして活用（抜けている視点などを補ってくれる） 　　 ‐ 指示すれば、報告書形式で仕上げてくれる為、レビュー結果をフィードバックしやすい 💡 AIを活用することで、レビューを行うデメリット 　　‐ レビュー対象の体裁を事前に整える必要あり（必要に応じて画像や Mermaid記法にするなど） 　　 - レビュー対象のコンテキスト量が多い場合、かなり手間が掛かる
39. テストケースについて 💡 テストケース作成を行うにあたり、いくつか決めることがあります。 　　 ‐ テスト設計書、仕様書などの作成元とする資料のファイルフォーマット 　　 ‐ 作成時の出力方法（可読性の意味で csvを推奨：Excel化やスプシの転用も容易） 　　　＊Googledriveダイレクトに入れる方法もあるが、セキュリティ面で推奨できない 【テストケースの使用用途（新規プロジェジェクト？保守プロジェクト？回帰テスト？）】 　　テスト実行と一気通貫を想定した場合 ... 　◆コーディングによる APIを使って自動テストを実行する想定の例 　　　　‐ シフトレフト（テスト対象が完成していない状態で実行させる想定） 　　　　　 →仕様書を必要に応じて、データ駆動型にして、画面仕様から組み立てる実装 　　　　‐ シフトライト（テスト対象が完成している状態で実行させる想定） 　　　　　 →テスト対象をクローリングして、各要素に仕様を当て込む実装 　◆MCPによる自動テストを実行する想定の例 　　 ‐ AIが理解しやすいような用語、意味を利用する必要あり（曖昧さがあると挙動が変化するため）
40. テストケースについて モーダル 人の作業を支援するといった位置づけが主になります。 - テストケース作成は他のドキュメント作成と比較して、 AI側で連続して推論することとなる為、記載量が少ないです。 　*高度なモデルであっても、一度に沢山作成できるといったわけではない為 　 注意が必要。（ここに夢を見てはダメです） 　また、プロンプトによる工夫も必要となります。 　*AIが手を抜くと、 ”同上”、”‥”のような省略を行うケースがあるため、 防止が必要。 - 出力して欲しいカラムはプロンプトで定義しておく必要があります。 - 仕様を読み込ませるコンテキスト量とテストケース作成量のバランスを 取りながら生成させる必要があります。
41. テストケースについて API利用 ‐ AIを利用すれば、かなり時短で実装自体に時間はかからないですが、 内容の精度を上げるためのプロンプト調整に時間が掛かります。 　また、テスト実行自動化と一気通貫で利用することを踏まえた場合、 　実装はテスト計画書、テスト設計書に比べると難易度は高いです。 ‐ RAGとしての利用はテキストデータ (JSON、markdown、CSVなど）、 データストア、 NotionDBなど、いくつか工夫を重ねることで可能と 思います（筆者はまだ実装中） 　*RAGのフォーマットなどは事前に定めておく必要あり ‐ テストケースが重複しないための処理、 RAGとして取得している値を 漏らさずにする処理が必要になります。 　*重複させないようにするのは困難であるため、意味的重複を排除する必要あり
42. テストケースについて API利用 ‐ 「テスト観点」のタグ付けを行うと、 AI判断のブレが大きくなるため、 ISO起点でnormal(正常系） /edge（異常系）で分割しておく方が AI側は理解しやすい（テスト観点は何度やってもダメでした） 　* ただ、Geminiはなぜか NoteBookLM上ではテスト観点の概念が 分かっている模様（ただし、 Geminiなりにひねり出した感じがする） ‐ 「テキストボックス」などの様々な値が入力できるものについては、 「データ駆動」で仕様を落とし込みを行い所定のファイルを キャッシュなりファイルで読み込める状態にしておく方が利便性は高い 　 *全てのパラメータ化を行うと肥大化するため、 「パラメータ用のテストデータ」ファイルを用意しておく方が望ましい - AIによる自己レビューを実行する場合、スコア化させておくと AIが自己レビューしやすくなります。 ‐ 作成したものを NoteBookLMに入れて、仕様と照らし合わせる荒業も利用可能
43. テストケース作成について ノートブック型 ダイアログ利用 ‐ モーダルよりも作成数は極端に少ないものの、 全てエビデンス付きで取得されるため、出力の信頼度が最も高い 　 ただし、出力したいカラムを必ず指定して、機能などを絞り込む作業が必須 💡 AIを活用することで、テストケース作成を行うメリット 　　‐ 一定のルールに従って、作成させることができ、誤字脱字、コピペミスがない 　　 ‐ 他のテストドキュメントと比較して、段階的に出力できるのでレビューが行いやすい 💡 AIを活用することで、テストケース作成を行うデメリット 　　‐ 仕様書のフォーマットを定めておく必要があり、準備にも相応の時間が掛かる 　　 - 意味的重複されたテストケースが生成されることがある
44. テストスクリプトについて 💡 テストスクリプト生成にあたり、いくつか決めることがあります。 　　 ‐ テスト設計書、仕様書などの作成元とする資料のファイルフォーマット 　　 ‐ テスト自動化のスクリプト選定（ Playwright、Selenium　など） 　　 - 作成時の言語の選定 【MCPとコーディングによる API利用】 　どちらが良さそうかは、実際にチャレンジしてみて考えた方が良いと思います。 　◆コーディングによる APIを利用 　　　→テスト対象の HTML、JSと仕様書を RAGにしてテストスクリプトを実装させる 　◆MCPによる自動テストを実行する想定（テスト実行との一気通貫） 　　　‐ MCPで要素を取りながら、テストスクリプトを実装させる（要素取得作業がかなり楽になる） 　　　 * ただし、実装が完了していることが条件 　　感触として、テストスクリプトを初見で作成するなら、 MCP経由で作成した方が楽かと思います。
45. テストスクリプトについて モーダル 人の作業を支援するといった位置づけが主になります。 - MCP前提だとかなり楽になります。 　モーダル単体だと書き慣れている方なら良いですが、 　初見でチャレンジされる方は結構面倒です。 - スクリプトを生成するにあたり、生成リストを用意しておくと 　かなり楽に管理できます。（途中で迷子にならない） - プロンプト指示する際には、言語や記載例も用意しておくと良いです。 API利用 - スクリプトの自動生成は PlayWriteなどをLangChainでラッパーを作っておき、 　実装を代替させることは可能ですが、そもそものシナリオ検討も行う必要が 　あるため、敷居は高めです。 - 作成したいスクリプトを AIを利用してコーディングした方が圧倒的に早いです。 - 出力されるレポートを自前カスタマイズもできます（多少面倒ですが）
46. テストスクリプトについて ノートブック型 ダイアログ利用 ‐ 残念ながら NoteBookLMでは記載はできません （将来的には記載できるようになるかもしれませんが） 💡 AIを活用することで、テストケース作成を行うメリット 　　‐ MCPを取得することで要素を取得したり、確認するといったこれまでの煩わしい作業から解放 　　 ‐ すでにテストスクリプトを書き慣れていれば、修正作業などはかなり便利 💡 AIを活用することで、テストケース作成を行うデメリット 　　‐ APIを使った実装を行う場合、相応の時間とコストが掛かる 　　 - MCPで操作が難しい部分の実装が必要になる（当然ですが ...）
47. テスト実行について 💡 テスト実行にあたり、いくつか決めることがあります。 　　 ‐ テストケースなどの実行対象とするドキュメント（ CSVが一番わかりやすい） 　　 ‐ 実行した結果の管理方法 モーダル ‐ 基本的には MCPを利用したテスト実行となります。 　実行しても、操作が思うように動作しないことがよくあります。 　（目的を達成する為の手段は選ばずに操作するため） 　また、セキュリティテスト、負荷テストを行うことはできません。 💡参考：Operatorで実行した結果 ‐ 20ケースを投げたところ、最初の画面遷移から 5分以上経過しても 操作できませんでした。 * ケース数が少なければ、動作するかもしれませんが、 現時点では MCPよりはるかに遅いです
48. テスト実行について ノートブック型 ダイアログ利用 ‐ 残念ながら NoteBookLMでは実行はできません API利用 - 自然言語によるの自動実行は PlayWriteなどをLangChainでラッパーを作り、 　実装することは可能ですが、物量も多く敷居は高めです。 - 負荷テスト、クロスブラウザテスト、 APIテスト、 　モバイルテストは別途実装が必要となります。 - 出力されるレポートを自前カスタマイズもできます - テスト内容によっては同期／非同期の実装も必要となります。 💡 AIを活用することで、テスト実行を行うメリット 　　‐ 自然言語でテスト自動実行が可能 💡 AIを活用することで、テスト実行を行うデメリット 　　‐ APIを使った自然言語によるテスト自動化実装を行う場合、相応の時間とコストが掛かる 　　 - テスト設計自動化と整合性を合わせながら実装する場合、非常に工数が掛かる
49. テスト報告書について 💡 テスト報告書を作成するにあたり、いくつか決めることがあります。 　　 ‐ テスト結果一覧、BTS　など（CSVが一番わかりやすい） 　　 ‐ 報告書のフォーマット（ Markdown、HTMLを推奨） モーダル ‐ 表形式にまとめるべきもの、文章で作成すべき内容など 　いくつかに分割して生成するようにします。 - 不具合分析はポイントを絞り込んだ上で生成する方が望ましい。 - MCPを利用して BTSへ直接分析を問い合わせる方法もあります。 💡参考： ‐ コンテキスト数が多いモデルを利用して、最初に Markdownのガイドラインを 　事前に渡しておくことが必要。
50. テスト報告書について API利用 ‐ 不具合分析については、ステータス毎またはカテゴリ毎に CSVで出力させます。 　CSVファイルを出力後に 1チケット毎に安価モデルで簡易分析させた方が 　コスト的にも安心かつ、精度が高くなるポイントです。 　* 過去のコメントも取得しておくと、無効起票の内容も分析可能 　* 内閣府APIで祝日日を取得して、起票から Closeまでの営業日数計算などを 　 実装しておくと、営業日ベースの分析も行ってくれます。 　出力後は高価なモデルを利用して、包括的な分析をさせることができます。 ‐ テスト計画書、設計書と同様に報告書のフォーマットを作成しておきましょう。 ‐ グラフ作成などは HTMLで埋め込みを行います。 　ゾーン分析などの図示が必要なものは SVG形式にするなどの方法があります。
51. テスト報告書について ノートブック型 ダイアログ利用 ‐ 簡易分析はできるものの、見解などの出力が甘いです。 　* QAエンジニアの記載するような一歩踏み込んだ分析になりません 💡 AIを活用することで、テスト報告書を作成するメリット 　　- APIを活用すれば実用レベルに限りなく近いものが出力できるようになる 　　　* 生成AIにおける効果が最も発揮しやすいため 　　 ‐ 生成されたものをレビューする時間も精度が高い為、時間を多く取られることがない 💡 AIを活用することで、テスト報告書を作成するデメリット 　　‐ BTSのカラム内容がPJ毎に異なる場合、実装ファイルを分けるか条件分岐処理が必要
52. 他にも活用できたこと Webモーダルから行ったこと ‐ 説明が難しい内容の言語化（抽象度コントロールが行いやすい） ‐ 自身の考えているプロセス、フロー、処理を図示化（フローチャートなど） - 会議の議事録の精査（ただし、元データの RAGに依存するが、Teamsのデータは精度が低い） - インフラの課題と問題点の分析（ API実装でも対応できそうな内容） - 仕様理解のための整理／壁打ち - 利用頻度が高いプロンプトの定型化 - MCPを利用して直接チケット起票
53. 将来的に必要となるかもしれないポイント 💡 AI思考空間設計 　　‐ AIの思考や推論をソフトウェアテストとしてコントロールする手法などが 　　　必要になるかもしれない。（高度な依頼を簡易的なプロンプトでは実現が難しい） 💡 ドキュメント品質の担保（既存資産の見直しまたは改善活動） 　　‐ AIが理解しやすい品質になっているかどうかを担保するための活動。 💡 AIありきを前提で考える工数算出方法 　　‐ このあたりは色々と調査する必要があるかもしれない。 これまで PoC的に色々な利用を行ってきている中で、気づいたポイントを記載しておきます。