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

ソフトウェアテストの AI活用猫おじさんの PoC実験結果 (2025/7 Ver1.25)

PoCにおける目的私のAIを活用した PoCの目的を以下へ列挙しておきます。　・　自分の意思をAIに伝えた上で、どこまでAIが対応できるのか？　・　どこまでAPI実装によりテスト工程の自動化を実現できるのか？　　 (できること、できないこと、前提条件、　　　他の方が同様に再現させる上で課題となることは何か？) 　・　作ってみた結果の精度はどうなのか？

更新履歴 No Ver 内容担当日付 1 1.00 初版発行 fumi.kato
2025/4/27 2 1.10 タイトルを変更更新履歴を追加以下を補足資料へ移動　　- テスト計画書について　　- テスト設計書について　　- レビューについて　　- テストケースについて　　- テストスクリプトについて　　- テスト実行について　　- テスト報告書について fumi.kato 2025/6/1 Ver1.10更新ページ

更新履歴 No Ver 内容担当日付 3 1.20 「サンプリングプロジェクト」を追加「AIを活用してテスト計画を支援」を追加
fumi.kato 2025/6/9 4 1.25 「AIを活用してテストケースの作成 (Draft)」を追加 fumi.kato 2025/7/13 Ver1.10更新ページ

最初にお伝えしたいこと・全体的に人の作業は支援できるが、 AIで全て「0 -> 100」を実現には至らない。　全量のAIで行うにはまだ遠いものの　 1年前と比較すると飛躍的にできることのバリエーションが増えた。
　　LLMの台頭によりこれまでのテスト実行自動化を除き、　　現時点で「0 ->100」を完全実現できたのはテスト結果報告書のみ　　＊企業文化によっては、実現できないかもしれないが、最も「 0 ->100」に近い認識・ AI活用をイチから進めるには、相応の時間 /コストが必要　　夢をみず、現実的にできることから着手する方が望ましい　　実験的なPoCも非常に時間が掛かるので、今回はその見解も踏まえている。・ AIが出力されたものはレビューに時間が掛かり、一意に出力されない　　デメリットとして認識しておくこと。むしろ、活用するならその覚悟が必要。　　当たり前として認識し、周りにも周知しておく方が良い。

はじめに・　AIを活用したソフトウェアテストに関するドキュメントとして記載しています。　「2025年5月」時点の更新版となります。・　以下については、あらかじめご了承ください。　　‐　あくまで実用してみた結果などを踏まえている為、　　　ベストプラクティスはご自身の企業およびプロジェクトによって異なります　　‐　新しい生成AIモデル、アプリ層のサービスが提供された場合、　　　これらの記載されている前提が大きく変化する可能性があります
　　‐　モデル等の所感はあくまで個人の所感です。　　　個人個人に見合った最適なモデルを見つけて頂くことをお勧めします - 今回、API利用についてはOpenAIのモデルをサンプリングしています。　　　他のモデルと性能変化がある点についてはご承知おきください - 単体テストにおける活用は様々な記事が出ている為、そちらをご参照ください

生成AIを活用する上で意識すべき点　AIを日々利用し続ける事のメリット　　　- 毎日会話することで AIの苦手な点、得意な点を理解できるようになります。　　　　　以下のような整理が個人でも出来るようになります（あくまで個人の感想です）　　　　　　　- 利用に慣れると、他の Closedモデルとの差異が理解できるようになり、
　　　使い分けがクリアに行えるようになります。　　　- モデルの特性を知ることで、ハルシネーションのポイントも　　　理解できるようになってきます。　　　　Gemini2.5　…コンテキスト数が多く、 ZeroShotは得意だが、　　　　　　　　　　　ソースコード記述は得意ではない（できないわけではない）　　　　　　　　　　　コンテキストの軌道修正がしづらい。　ChatGPT o1 Pro　…コンテキスト数は少ないが、エラーが発生しない　　　　　　　　　　　無難なソースコードを記載をすることが多い

生成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

生成AIを活用する上で意識すべき点　IDEのルール設定、sysytemプロンプトとhuman(user)プロンプト　　- IDEのルール＆MDC設定：コード品質・一貫性を機械的に担保する（静的解析・整形・リントなど）コード整形ルール、型チェック設定　　- system prompt　　　：
LLM の“人格”・振る舞い・制約を規定し、会話全体を統制する会話全体のフォーマットを絶対に守らせたい場合に利用　　- human (user) prompt ：ユーザが実際にやらせたいタスク・質問を記述。その瞬間だけ必要な指示

サンプリングプロジェクト

サンプリングプロジェクト　・　Hotel Planisphere 　　　＊ホテル予約のテスト自動化サイトです。参考URL：https://hotel-example-site.takeyaqa.dev/ja/

AIを活用してテストケース作成（ Draft版）

はじめに今回はあくまで Drft版としています。テスト実行自動化の際に改めてチューニングの可能性があると考えているのが理由です。まだまだ拡張させる必要がありますが、参考程度になればと思い記載してみました。

準備物以下はPoCにあたっての準備したもの　・　開発IDE環境（CursorのProを利用すると便利かも）　・　生成AIのAPIの発行（APIは gpt 4.1-miniを利用）　・　Markdown化された仕様書・　ソースコード実装で活用するAI（Gemini 2.5 Proを利用）
　　　＊ソースコード量が2000行程度まではClaudeを利用　・　APIで利用するマネー（7000円ぐらい利用）　・　やりきる心と諦めないメンタル

参考）利用しているライブラリなど all - MiniLM-L6-v2 　仕様の内容をベクトル化するために利用 NetworkX 　グラフ理論を扱う為に利用。状態遷移モデルなどで利用。 NuSMV 　
仕様間の論理矛盾の確認、論理プロパティの成立を厳密に検証するために利用。 scikit-learn 　状態遷移モデルにおいて、ベクトルの意味の近さを自動的に　クラスタリングするために使用

【参考】今回利用した数式 (1 / 2) Automaton: A = (S, Σ, δ,
s₀, F) S: 状態の有限集合 (例: 「ログイン前」「商品選択中」 ) Σ: イベント(入力)の有限集合 (例: 「ログインボタン押下」) δ: S × Σ → S 遷移関数 (例: 「ログイン前」状態で「ログインボタン押下」すると「商品選択中」状態へ ) s₀: 初期状態 F: 受理状態(終了状態)の集合 Objective: Maximize Σ (risk_j * coverage_ij * x_i) // risk_j: 要求jのリスク, x_i:テストiを実行するか Subject to: Σ (cost_i * x_i) ≤ Budget // 総コストは予算内に収める x_i ∈ {0, 1} (実行する/しない) Decision Table: DT = (C, A, R) C: 条件の有限集合 (例: 「会員ランクはゴールドか？」「購入金額は 1万円以上か？」) A: アクションの有限集合 (例: 「送料無料を適用」「割引クーポンを付与」 ) R: ルールの集合。各ルールは、条件の真偽値の組み合わせと、実行すべきアクション (X)のマッピング (例: IF c₁=True AND c₂=True THEN a₁=X AND a₂=X)

【参考】今回利用した数式 (2 / 2) BehaviorSpec (Given-When-Then) ↓ CTL Formula (例:
AG(リクエスト → AF(レスポンス))) A: 全てのパスで (Always) G: 全ての状態で (Globally) F: いつかは (Finally) Test Goal: Verify that for a given Automaton M and a CTL formula φ derived from a BDD spec, M ⊨ φ (Automaton M satisfies the property φ) Goal: Find Test Set T that satisfies the following: ∀ pᵢ, pₚ (i≠j) in Parameters ∀ vₐ ∈ domain(pᵢ), vₑ ∈ domain(pₚ) ∃ t ∈ T such that t contains (pᵢ=vₐ AND pₚ=vₑ) ... while minimizing |T| (the number of test cases) Parameter: p Domain: Dₚ = [min, max] Test Values (Tₚ): {min-ε, min, min+ε, (min+max)/2, max-ε, max, max+ε} ε: パラメータが取りうる最小の変化量 (例: 整数なら1)

課題の共有 (1/2) AIでテストケースを作成していると課題が浮き彫りに ... ・ AIにテストケース作成を依頼しても、出力ロジックがわからない　 * 人が作成する場合、中間生成物があるので思考を追える・テスト対象から欲しいテストケースが生成されない
　 * AIへ指示しても、思った形にテストケースが生成されない・チャット形式で質問しても再現性の担保が難しい　 * 毎回同じプロンプトで質問なり指示を出せているか不透明

課題の共有 (2/2) AI利用以前の課題も ... ・複数名でテストケース作成作業を行う場合の認識齟齬　 * 5名程度ならコントロールできる範囲であっても5名→10名に増えると、　　　パラメータ抽出、シナリオテストの考え方などの意識が　　　合わせづらい場面に遭遇する（PJが多いとさらにややこしいことに...）
・テストケース作成に至るドキュメントの不足　 * 「チームメンバー全員」が必ず同じ解像度であることは稀。　　　業務知識（実力差、経験差、知識差）のギャップがありながらも　　　共同でテストケースを作成するとバラツキが発生する。

今回行ったことテストケースの生成理論を明確にする数理モデルなどを使って、AIへ引き渡す前に仕様の前捌き処理を行う生成理論を人間が可読できるレベルでアウトプットする生成理論の読解を容易とするため、どのような状態から出力されるかを把握できるようにレポート化する自然言語によるテスト実行自動化を前提としたテストケースにする自然言語でテスト実行ができるようなルールを決めて生成させる

テストケース生成過程の簡易比較テストケース生成までを簡略化して整理仕様書中間生成物テストケース仕様書 LLMへ投入テストケース
仕様書 LLMで抽出テストケース LLMへ投入人力 LLM直投入今回の手法生成理論の構築

全体像の概略仕様書読み込み JSON形式テストケースRAWファイル LLMへ投入 JOSN形式テストケース CSV形式テストケース Markdown形式レポート生成理論の構築 LLMへ投入
JOSN形式テストデータ JSON形式エンリッチ整理 JSON形式形式仕様抽出処理出力画面仕様書入力機能仕様書非機能仕様書業務フロー仕様書ここがとても重要！そして、とても難しい JSON形式 BDD用データ

仕様書をどのように分解しているのか？ Step1：Markdownの仕様を見出し毎に分割丸々仕様を利用せずに、「## バリデーションルール」といった形で分割 Step2：文章の各ブロックを all-miniLM-L6-v2でベクトル変換ベクトル化して項目にラベル付け(ここで変換したものは、状態遷移で利用) Step3：LLMを利用して、テストケース生成に必要な項目の抽出パラメータ、状態、論理ルールなどを抽出して、JSONへ出力 Step4：LLMを利用して、エンリッチ対応を行う
計算ルール数式化、入出力項目定義、シナリオ着想源などをJSONへ出力 Step5：テストデータ用の JSONファイルを生成入力項目に必要なテストデータをJSONへ出力

状態遷移の処理について Step1：JSONからStates(状態)、Transitions(遷移)を読み込む・networkxのライブラリを利用して、読み込んだ情報のグラフデータを構築・構築したデータをAutomaton(オートマトン)オブジェクトとしてメモリに格納 Step2：状態遷移の骨子生成・Automaton(オートマトン)オブジェクトからC0、C1をピックアップ・ピックアップした内容からテストケースrawファイルを生成出力内容：・状態遷移図・状態遷移表

境界値の処理について Step1：JSONからデータ型と入力範囲を読み込む・入力値、日付などから動的に、max値、min値、うるう年などを格納 Step2：One-at-a-Time ・正常系のテスト生成パターンを作成し、それをベースにたのパターンを作成・パターン化したものをテストケースrawファイルとして生成出力内容：・テスト対象およびパラメータ一覧

ペアワイズの処理について Step1：JSONの入出力項目と制約事項から抽出・境界値、異常値などから値を抽出し、制約が定義されている場合はその項目から　ありえない組み合わせを除外。　また、ピックアップされた因子に重複した内容がないかをチェック。 Step2：最適なシナリオの選定・ allpairspyのライブラリを呼び出して、組み合わせ処理を実行し、　組み合わせた結果をテストケースrawファイルとして生成出力内容：
・組み合わせ項目一覧

デシジョンテーブルの処理について Step1：JSONの論理ルール項目を読み込み、分類と条件パターンを生成・JSONの論理ルールからバリデーションルールと成功/計算ルールに分類。　各バリデーションルールが単独で成立するよう最小の条件セット(真・偽)を生成。また、全てのバリデーションルールが発動しないハッピーパスの条件も生成。 Step2：最適なシナリオの選定・「Step1」では「年齢 > 20 :
True」といった形で記載されている為、　具体的な値に変換してrawファイルを生成。　金額などが含まれている場合、JSON内の計算ルールに基づき、自動で再計算。出力内容：・デシジョンテーブル

【参考】BDDを活用した仕様整合性のチェック Step1：JSON(BDD用）を読み込み、オートマトンと照合・Thenで記述された期待結果をCTLに変換し、NuSMVの外部チェッカーを利用して　状態遷移モデルが論理プロパティを満たすかどうかを証明。 Step2：論理の曖昧さを LLMが解析・振る舞いベースで論理の曖昧さをLLMが分析して、仕様の課題を抽出。出力内容：・論理整合性の検証結果

【参考】自然言語でテストケースを LLMに書かせるポイント①： PlayWriteを用いたテストの自動化を想定　という前提条件・なぜか、テストケースの出力内容が未定義よりも出力内容が均一化。ポイント②：テスト開始元の URLを手順の1つ目で必ず定義しておく・自然言語でテスト実行する為に必要です。MCPであっても必要なので。ポイント③：日本語で記載するように定義しておく・ごく稀に英語となるケース(100回ぐらい行って、1回あるかないかぐらい）が
　あるので、日本語で記載するように定義しておきましょう。参考程度ですが、 APIを利用してプロンプトで指示する上でのポイントを記載。

作成してみた所感・夜に実行したら、朝にはテストケース作成が完了していたのはかなり新鮮・テスト技法がテストケース作成数の論理ガードレールとなっているため、　テスト項目を LLMが無制限に作ることがない（これはありがたい）・論理の組み立ては人によってそれぞれ異なる為、　実装した人によっては、面白いものができるかもしれない・論理の組み立てによっては新しいテスト方法が生まれるような可能性は感じた・他にも実装できていないテストがあるので、取り込んだら更新していきたい　＊現状もまだまだ改善の余地がありそう...

【参考】論理整合性の確認

【参考】シナリオ一覧

【参考】デシジョンテーブル

AIを活用してテスト計画を支援

AIを活用してテスト計画を支援以下をポイントに解説を進めていきます。　・　プロジェクト計画書および要求定義または要件定義の読み込み　・　テスト計画書の Markdownファイルの生成　実装難易度は低めです。プロンプトとMarkdownを適切に処理すれば、　対応できるようになっています。

AIを活用してテスト計画を支援（準備物一覧）以下はPoCにあたっての準備したもの　・　開発IDE環境（CursorのProを利用すると便利かも）　・　生成AIのAPIの発行　　（APIは gpt 4.1-miniを利用。一部はgpt 4.1を利用）　・　プロジェクト計画書、要求定義などはMarkdown化しておく・　ソースコード実装で活用するAI（Gemini
2.5 Proを利用）　・　APIで利用するマネー（2000円ぐらい利用）　・　やりきる心と諦めないメンタル（ここが一番重要）

AIを活用してテスト計画を支援（処理順序）入力データ解析キーワード分類・処理の構造目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成図表の検証と自動修正テスト計画書 Markdown生成読み込んだMarkdownの解析
H2見出しをキーワード辞書分類目次を親子関係の階層構造に変換目次の各セクションへAIを割り当て本文と図表の作成 Mermaid形式の軽微な問題を自動修正テスト計画書を出力以下が処理順となります。 1 2 3 4 5 6 7

AIを活用してテスト計画を支援（処理順序）入力データ解析キーワード分類・処理の構造目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成図表の検証と自動修正テスト計画書 Markdown生成「1」〜「2」で行っているマッピングについて記載
1 2 3 4 5 6 7 非構造化テキストを、 AIが扱いやすい半構造化データに変換を行うマッピング： MarkdownにあるH2の見出しを抽出。あらかじめ定義している辞書の見出しキーワードと照合させることで、後にAIが「スケジュールについて」を問われた際、関連情報だけをピンポイントで参照できるようにする。今回はキーワードによるマッピングとなるが、セクション単位でさらに細かいマッピングを実装させることも可能。＊プロジェクト計画書が定型フォーマットとして存在するかどうか次第で検討の余地あり

AIを活用してテスト計画を支援（処理順序）入力データ解析キーワード分類・処理の構造目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成図表の検証と自動修正テスト計画書 Markdown生成「3」で行っている目次オブジェクトツリーについて記載
1 2 3 4 5 6 7 ドキュメントの骨格となる目次を、プログラムが操作可能なデータ構造に変換目次オブジェクトツリーの生成：あらかじめ定義している「テスト計画時に作成する目次構造」の階層を解析して、各行のインデントを確認。タイトル、階層、子要素リストといった属性をオブジェクトに変換。再帰的に処理を行い、親子関係を持つツリー構造をメモリ上に構築。この処理を行うことで、AIが各目次のセクションに記載しながらも、今現在はどのセクションに対して、回答しているかをわかる様にしている。

AIを活用してテスト計画を支援（処理順序）入力データ解析キーワード分類・処理の構造目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成図表の検証と自動修正テスト計画書 Markdown生成「4」のプロンプトの割り当てについて記載
1 2 3 4 5 6 7 各セクションに対して、様々なペルソナを設定している思考を AIに渡すプロンプトの割り当て：「３」で作成された目次と「２」で構造化されたプロジェクトを情報に対して、最適と思われるプロンプトを検索して、プロンプトの割り当てを行う。ここで、実際のテスト計画書にある目次セクション毎にプロンプトを割り当てることで各セクション毎にユニークなプロンプト内容を指示できるようになる。＊要はスケジュールならスケジュール、戦略なら戦略用のプロンプトを個別に用意

AIを活用してテスト計画を支援（処理順序）入力データ解析キーワード分類・処理の構造目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成図表の検証と自動修正テスト計画書 Markdown生成「5」のプロンプトについて解説（後述の出力サンプルも確認してね）
1 2 3 4 5 6 7 プロンプトで思考を強制ペルソナ：ペルソナの設定はセクション毎に変更。例えば...リスク管理ではリスクアナリストとするといった具合にテストの文脈ではなく、各セクション毎に専門家を設定。思考の強制：根本分析：情報をインプットして分析論理的導出とエビデンスの提示：分析結果から根拠を明確にする具体的な計画：根拠に基づいて、実行できるアクションプランを記述これにより、生成する思考の統一させる。

AIを活用してテスト計画を支援（処理順序）入力データ解析キーワード分類・処理の構造目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成図表の検証と自動修正テスト計画書 Markdown生成「6」〜「7」で行っている文脈の維持方法について記載
1 2 3 4 5 6 7 文脈維持をさせるために、要約のバトンリレーを実施要約のバントリレー：膨大なドキュメント量となっても一貫性を保てるように、要約のバトンリレーを以下のように行っている。（文脈維持のキモ）セクション (N-1)の要約した文章を取得 ↓ 要約を踏まえて、セクション (N)をAIで記載 ↓ 生成されたセクション (N)を要約 ↓ 以下、ループ

テスト計画書作成サンプル (1)

AI活用によるテスト計画の考察多角的なインサイトを得られそう : 人間が抵抗感がある戦略、記載すべき内容の叩き台を約 10分で生成。プロンプトのペルソナでは QAエンジニア、品証保証をあえて設定せずに、セクションにあわせて各専門家（多角的視点）のペルソナを注入することで、普段では得られないインサイトがあった。 AIの強み（認知バイアスの破壊） : 感情と心理的抵抗（「もし、不具合が残っていて自分のせいにされたらどうしよう」という不安（損失回避性））がないため、テストを行わないもの
はバッサリと切り捨てる戦略を容易に行える。通常はリソース配分、政治的な力学を想定したりもするが、 LLMは「プロジェクトとビジネスの成功確率を最大化」を目的として設定している関係上、ある種の合理的な提案してくる部分は面白さがあると思えた。また、 LLMは過去の膨大なインシデントを学習しているため、「ブラックスワンリスク」いわば、人間が想定しづらい極端な悲観シナリオを生成して、その内容を提案することができるのは、プロンプト次第でミッションクリティカルなビジネスにおける有用性は感じた。 AIの限界 : AIはあくまで過去のデータに基づいた提案を行う為、斬新な未知のドメインなどの対応が非常に苦手であり、未知の出典先などのリンクは別途ソースを探す為の処理が別途必要となる。また、依然として、プロジェクト計画書、要求定義などの質に左右される。 RAGの質が悪ければ出力結果も曖昧なものとなるので成果物のレビューなどは引き続き課題となる。議論の叩き台としては有効だと感じた : 生成されたドキュメントは認知バイアスを排除した上で、プロジェクト成功のための品質を根幹としているため、テストの取捨選択などはステークホルダーを含めた議論には一定の有用性がありそうと感じた。

AI活用によるテスト計画の考察項目人による作業 AIによる共同作業計画書の根拠と一貫性担当者の記憶と解釈に依存する為、計画の根拠が曖昧になり、ドキュメントの追従漏れが発生しやすいキーワードマッピングにより構造化され、なおかつ一貫性を保てる様に文脈を維持し続けるような処理を行える
戦略の質と多角性担当者の経験や知識に（良くも悪くも）左右される必要に応じて、プロンプトで多角的なペルソナが設定可能思考プロセス個人の頭の中にあるため、構造化して表現するために多くの時間が必要となる導き出した根拠を思考プロセス（分析、論理的導出、計画立案）を矯正させることができ、アウトプットすることが可能成果物の安定性手作業によるミスが避けらない Mermaid形式出力にミスが目立つ保守性手作業による修正に時間がかかる半自動化で大幅な時間短縮が可能人による作業と簡易的に比較

まとめ　・　AIの成果物についてのレビューは必要　　　　　＊完全にドキュメントとプロンプトの内容に大きく依存するため、　　　　　　プロジェクト計画書、要求定義の品質向上活動とプロンプトの工夫と調整は必須　・　小さいプロジェクトなら IDEのチャットと併用処理でもよさそう　　　　　＊長文にするなら本書のように API処理が良いです。 IDEは限界があるため　・　（本項とは逸脱するが）色々なペルソナでテスト計画書が作れる
　　　　　＊AIしかできないペルソナ設定で同じプロジェクトのテスト計画書が様々な視点で　　　　　　作成できるので、色々な示唆が得られるのは非常に面白いです。

AIを活用してテスト設計を支援

AIを活用してテスト設計を支援以下をポイントに解説を進めていきます。　・　テスト設計の構築（仕様書の整理 =JSON化）　・　JSONから自然言語のテスト要件 /テスト条件の生成　最初にお伝えしておきますが、モデル名を除き、　　「1行もソースコードを記載せずに Vibe Codingで実装」しています。
　　よって、AIを使えば、誰でも実装できる可能性があります。

AIを活用してテスト設計を支援（準備物一覧）以下はPoCにあたっての準備したもの　・　開発IDE環境（CursorのProを利用すると便利かも）　・　生成AIのAPIの発行（APIは gpt 4.1-miniを利用）　・　画面仕様、機能仕様、非機能仕様、業務フロー　などを　　あらかじめ、Markdown化しておく・　ソースコード実装で活用するAI（Gemini
2.5 Proを利用）　・　APIで利用するマネー（7500〜1万円ぐらい利用した）　・　やりきる心と諦めないメンタル（ここが一番重要）

AIを活用してテスト設計を支援（処理順序）入力データ解析構造・分類関係性解析ドキュメントカタログ構築詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 Markdown仕様書群の解析機能/画面/ワークフロー/非機能に分類
ID参照・自然言語関連付け各種convert処理 Mermaid解析・ステップ抽出 JSON統合・出力テスト要件・テスト条件・図表を出力以下が処理順となります。 JSON出力までは AIは未使用です。 1 2 3 4 5 6 7

AIを活用してテスト設計を支援（処理の一部について）入力データ解析構造・分類関係性解析ドキュメントカタログ構築詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 ChunkStore ：
解析したMarkdownのチャンクをメモリ上に保持し、IDによるアクセスや関連チャンクの取得機能を提供。処理のセッション内でのキャッシュデータとして保持。マッピング：一度解析した機能IDと関連画面情報のマッピングをキャッシュで保持。ベクトル検索：仕様書チャンクのテキストからベクトル埋め込みを生成し、ChromaDBに格納。「1」〜「5」で活用しているキャッシュ処理について記載 1 2 3 4 5 6 7 キャッシュ以外にも並列処理/リトライ処理などはありますが、よしなにAIが生成してくれるだろうと思うので解説は割愛。指定しないとやってくれなさそうな処理のみ記載しています。

AIを活用してテスト設計を支援（処理の一部について）入力データ解析構造・分類関係性解析ドキュメントカタログ構築詳細ワークフロー生成 JSON出力 AI起動テスト要件生成自動ID生成: FUNC-001_IP01,
FUNC-001_IP02 のように一意 IDを自動付与構造化抽出: Markdownテーブルから structured_items として配列データ化関係性推論: ファイル名や内容から機能 -画面-ワークフローの関連性を検出メタデータ保持: 元ファイルパスや行番号などトレーサビリティ情報を維持「6」を生成するにあたり行っている処理 1 2 3 4 5 6 7

仕様書の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" },

AIを活用してテスト設計を支援（処理の一部について）入力データ解析構造・分類関係性解析ドキュメントカタログ構築詳細ワークフロー生成 JSON出力 AI起動テスト要件生成 JSONからテスト設計を作成する処理は以下。ステップ1:
テスト要件(上位テスト要件)生成ステップ2: テスト条件(詳細インサイト)生成ステップ3: 関連性構築各詳細インサイトと上位テスト要件の IDリンクステップ4: Markdown構造化上位要件 → 詳細インサイト (タイプ別) 「7」で行っている処理について記載 1 2 3 4 5 6 7

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 - *期待/根拠*: [email protected]等の標準的なメール形式での認証成功 - *テストデータ *: 有効メールアドレスパターン一覧 - *タグ*: functional, authentication, email_validation

コード実行時のテスト設計書 (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 ```

(例）機能仕様から生成されるテスト条件 (詳細インサイト ) セキュリティ・コンプライアンス SecurityConsideration 内容: 入力に関連するセキュリティリスクと検証出力例: 「SQLインジェクション攻撃への脆弱性検証」 ComplianceCheck
内容: 法規制・業界標準への準拠確認出力例: 「個人情報保護法に基づく同意取得メカニズムの確認」出力検証・条件確認 OutputVerificationPoint 内容: 出力内容の正確性検証出力例: 「認証成功時のセッション ID生成形式確認」 PreConditionValidationPoint 内容: 事前条件の検証ポイント出力例: 「ユーザーアカウントの事前存在確認」 PostConditionVerificationPoint 内容: 事後条件の確認ポイント出力例: 「ログイン状態への適切な状態遷移確認」戦略的テスト観点 StrategicTestGoal 内容: 機能の成功を測定する具体的なテストゴール出力例: 「認証精度99%以上を達成すべきである」 KeyRiskArea 内容: 最も影響の大きいリスク領域の特定出力例: 「不正アクセスによるデータ漏洩リスク」 CoreTestStrategy 内容: 主要なテスト戦略の柱出力例: 「多層防御によるセキュリティ検証重視」

(例）機能仕様から生成されるテスト条件 (詳細インサイト ) 入力パラメータ検証 ValidInputCase 内容: 正常系の代表的なテストケース出力例: 「[email protected]等の標準メール形式での認証成功検証」 InvalidInputCase
内容: 異常系のテストケースと期待される動作出力例: 「無効メール形式入力時の適切なエラーメッセージ表示」 BoundaryValueAnalysis 内容: 境界値条件のテストケース出力例: 「パスワード長8文字未満・65文字超過での挙動確認」 DataCombination 内容: 複数パラメータの組み合わせテスト出力例: 「メール＋パスワードの有効・無効の全組み合わせ検証」その他 ExploratoryTestCharter 内容: 探索的テストのチャーター出力例: 「非典型的な認証シーケンスでの隠れた脆弱性探索」 SpecificationFeedback 内容: 仕様書の改善提案出力例: 「エラーコード定義の曖昧さ解消が必要」 NFRTestAspect 内容: 非機能要件テスト観点出力例: 「同時ログイン1000件での応答性能確認」

テスト設計作成サンプル (1)

AI活用によるテスト設計の考察初期ドラフト作成の効率化はできそう : 人間が数日～数週間を要する可能性のある多岐にわたるテスト要件群、戦略図、関連表の草案を、約 30分で生成できた。これを手作業で同様の粒度と網羅性で作成するのは非常に時間がかかる ...IDEのチャットを利用するよりも高速で対応できそう。観点の体系的網羅 : 定義された多様な観点を、仕様の各要素（機能、
UI要素、ユースケース）に機械的かつ体系的に適用できた。人間では見落としがちな組み合わせや特定の専門知識が必要な観点からのテストアイデアを系統的に洗い出すことができそう。トレーサビリティの手間を削減 : テスト要件とテスト条件間の関連付けを行うことで、テストの目的（何を検証するのか）とその手段（具体的にどう検証するのか）を明確に結びつけることができる。これにより、手作業での関連付けの手間を大幅に削減できそう。議論の叩き台としては有効だと感じた : 生成された具体的なテスト要件、 Mermaid形式の戦略図（テストレベル・スコープ図、リスクベース戦略図）、そしてドメイン特化型のリスク・テスト関連表は、チーム内で議論の「叩き台」として非常に有効だと考える。リスクベースアプローチに使えるかも : 「リスク・テスト関連表」では、ドメインにおける一般的なリスク、それに対応するテストタイプ、さらには使用するテスト技法が体系的に整理できる。また、Mermaid図においてもリスクの高いコンポーネントが強調表示させることができ、リスクベースドアプローチも利用できそう。

AI活用によるテスト設計の考察項目人による作業 AIによる共同作業仕様整理設計者が熟読し手動整理。解釈にばらつき、大規模では膨大な時間。 Markdownパーサー等が仕様を構造化・関連付け。初期理解・整理の効率化、網羅性向上。テスト要件定義
設計者の経験・知識に依存。網羅性・多様性はテスト設計者のスキル次第。構造化仕様に基づき LLMが多角的にテストインサイトを生成。アイデア出し効率化、多様な観点の網羅性向上。テストアーキテクチャ設計戦略、レベル、スコープ、リスク分析、図表作成を手作業で作成。 LLMが概念図や関連表を自動生成。戦略の可視化、共通認識醸成を促進。網羅性と一貫性人間の注意力・スキルに依存。大規模では変更追跡や一貫性維持が困難。機械処理とAI分析で抜け漏れリスク低減。中間成果物を介し一貫性向上。AIの解釈限界は考慮要。効率とスピード時間のかかる反復作業が多い。仕様変更対応も時間とコスト。自動化・半自動化で大幅な時間短縮・コスト削減。仕様変更にもある程度追随可能。成果物の品質設計者のスキル・経験・コンディション (集中力が...)に左右。レビューが重要。入力仕様・プロンプト・ LLM性能に依存。AI生成物は専門家のレビュー・修正が不可欠。人による作業と簡易的に比較

まとめ　・　AIの成果物についてのレビューは引き続き必要　　　　　＊相変わらず、出力されるテスト技法の名称が適当 (プロンプトで解決できるかな ..). 　　　　　＊昔に比べたらモデルが賢くなったのでレビュー指摘は減っている気が ...(気のせい？）　・　決まったタスクであれば、 API処理の方がよさそう　・　モデルが賢くなれば、更にインサイトを得られる出力ができそう
　・　自動化が Mustかと言われると、そうではないと考えるが　　圧倒的に初稿が楽なのは間違いない　　　　　＊流石にレビューするにあたって全然こちらが汲み取れない内容までは出てこない　　　　　　テスト技法の選定で適当な名前があったとしても、なんとなくやりたいことはわかる　　　　　＊レビューに時間が掛かったとしても、恩恵はありそう

補足資料 2025/4(Ver1.00)の記載内容

補足資料　　- テスト計画書について　　- テスト設計書について　　- レビューについて　　- テストケースについて　　-
テストスクリプトについて　　- テスト実行について　　- テスト報告書について

参考資料(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 が存在すると、すべてのリクエストで全文注入（非推奨）

テスト計画書について 💡 テスト計画書を作成するにあたり、いくつか決めることがあります。　　‐ テスト計画書の作成元とする資料のファイルフォーマット　　 ‐ 作成時の出力方法（可読性の意味で markdownを推奨）モーダル
人の作業を支援するといった位置づけが主になります。 ‐ IDEのモーダル作成であれば、自動でドキュメントに入力できるため、コピー作業などの雑務的な手間がなくなりますが、出力量が少ないです。出力量の参考： 1000行のプロジェクト計画書サンプル（ markdown）を　　　　　　　基にテスト計画書を依頼した場合 (ゼロショットの記載依頼 ) 　　　　　　Gemini2.5かつcursor利用：約250行　　　　　　Claude3.7sonetかつWebモーダル利用：約400行　　　　　　o1ProかつWebモーダル利用：約270行

テスト計画書について API利用 ‐ AIを利用すれば、かなり時短で実装自体に時間はかからないですが、内容の精度を上げるためのプロンプト調整に時間が掛かります。　また、図などを Mermaid形式で指定した場合、図が思った形で出力されないことが多いです（ 1/4ぐらいの確率で成功する程度） ‐
こちらも人の作業を支援する位置づけとはなりますが、モーダルよりも精度を上げることが可能です。 ‐ Mermaid形式で出力を検討している場合、表の箇所のみ HTMLにすることで、表の崩れを抑えることは可能です。　ただし、問題点として、 Markdownの改変がしづらくなる可能性があります。 ‐ 筆者はLangchainを利用して実装しています。

テスト計画書についてノートブック型ダイアログ利用 ‐ 一部作成はできるがテスト戦略なり、テスト方針のたたき台には利用可能です。　ただし、言葉は同じで意味が異なるものを取り扱う場合は注意してください。根拠についてもエビデンスはあるが、抽象度が高すぎるような指定の場合、　出力されない（回答を拒否される）ため、注意が必要です。 💡 AIを活用することで、テスト計画書を作成するメリット
　　‐ イントロダクションを考えてくれる（冒頭の記載を考えるが面倒）　　 ‐ とりあえず、APIを利用すると自分が記述すべき分量が圧倒的に減る 💡 AIを活用することで、テスト計画書を作成するデメリット　　‐ テスト計画書における各章の説明準備工数は必要　　　（記載しなくても書いてもらえるが、記載しておく方が望ましい）　　 - APIをコーディングする場合、プロンプトの微調整が必要

テスト設計書について 💡 テスト設計書を作成するにあたり、いくつか決めることがあります。　　 ‐ テスト計画書、要件定義などの作成元とする資料のファイルフォーマット　　 ‐ 作成時の出力方法（可読性の意味で markdownを推奨）
モーダル人の作業を支援するといった位置づけが主になります。 ‐ IDEのモーダル作成であれば、自動でドキュメントに入力できるため、コピー作業などの雑務的な手間がなくなりますが、出力量が少ないです。 💡参考：　表形式で出力がテスト計画書より多くなる為、安価なモデルは避けて　表形式を崩さずに出力できる高価なモデルを利用することをお勧めします　読み込ませるファイル数が多い場合、 Gemini2.5などのコンテキスト量が　多いモデルの利用を検討してください。

テスト設計書について API利用 ‐ こちらも人の作業を支援する位置づけとはなりますが、モーダルよりも精度を上げることが可能です ‐ 実装自体に時間はかからないですが、内容の精度を上げるための　プロンプト調整に時間が掛かります ‐ どうしてもテスト観点を加えたい場合、
Geminiは理解できるケースが　ありながらも、 ISO/IEC25010ベース、 AIが理解しやすい形になどする方が　望ましいです。ポイントは AIが理解できないものを入れないことです。 - AIの回答履歴を要約して履歴をトークンに含めつつ AIに回答させる必要が　あるため、トークンのキャッシュ、メモリ管理が必要となる場合があります。 ‐ 筆者はLangchainを利用して実装しています

テスト設計書についてノートブック型ダイアログ利用 ‐ 一部作成はできます。インフラなどを鑑みたテスト環境など、たたき台としては有用です。　表形式で出力するものなどは非常に見づらくなる点は注意が必要です。機能毎の詳細な出力を行うように指示することが必要です。 💡 AIを活用することで、テスト設計書を作成するメリット
　　‐ イントロダクションを考えてくれる（冒頭の記載を考えるが面倒）　　 ‐ とりあえず、APIを利用すると自分が記述すべき分量が圧倒的に減る 💡 AIを活用することで、テスト設計書を作成するデメリット　　‐ 記載にあたっての抽象化レベルのコントロールが必要　　 - 記載内容が細かい場合はトークン管理が必要

レビューについて 💡 レビューを行うにあたり、いくつか決めることがあります。　　 ‐ レビュー対象元の収集　　 ‐ 出力方法の検討（可読性の意味で markdownを推奨）
モーダル人の作業を支援するといった位置づけが主になります。 ‐ 画像、文章などいずれかをレビューのインプット対象とするが、　レビューを行う為のガイドラインなどは事前に準備を行い、ガイドラインを　含めたレビューを行うことで、一貫性があるレビューを行うことができます。 💡参考：　レビュー報告用のフォーマットを事前に用意して結果を出力できる形に　しておくとスムーズな出力ができ、統一感がある形となります。　レビュー対象のファイル数が多い場合、 Gemini2.5などのコンテキスト量が　多いモデルの利用を検討してください。

レビューについて API利用 ‐ レビューガイドラインをプロンプトに入れて、具体例を出した上で　指摘を行う方が高い効果を得られやすいです。　＊具体例がない状態でレビューを行うと、プロジェクトの状況を把握していない　　指摘が挙がってくるので注意が必要です。　　（例：手動テスト前提だが、テスト自動化の管理方法がない　など） ‐ 通常APIでは安価なモデルを利用するのが一般的ですが、
　安価なモデルでは複雑な思考に耐えられない為、安価なモデル以外の　利用をお勧めします。 ‐ 思考を追うような段階的なレビューを順次行う方が AI側で思考の整理が　行いやすいので、多段的なステップを踏ませるようなレビューの方が良いです - レビューを行った内容に対して、さらにループ処理を行うと　レビュー精度があがります。　（指摘も増える傾向にあるが、意味的重複削除処理は必要）

レビューについてノートブック型ダイアログ利用 ‐ レビューはできるものの、包括的なレビューを行うには不向きです。　ただ、ピンポイントレビューには一定の有効性はあるため、　範囲を絞り込んだ形で簡易レビューには利用できます。 💡 AIを活用することで、レビューを行うメリット　　‐
自身のレビューのプラス αとして活用（抜けている視点などを補ってくれる）　　 ‐ 指示すれば、報告書形式で仕上げてくれる為、レビュー結果をフィードバックしやすい 💡 AIを活用することで、レビューを行うデメリット　　‐ レビュー対象の体裁を事前に整える必要あり（必要に応じて画像や Mermaid記法にするなど）　　 - レビュー対象のコンテキスト量が多い場合、かなり手間が掛かる

テストケースについて 💡 テストケース作成を行うにあたり、いくつか決めることがあります。　　 ‐ テスト設計書、仕様書などの作成元とする資料のファイルフォーマット　　 ‐ 作成時の出力方法（可読性の意味で csvを推奨：Excel化やスプシの転用も容易）
　　　＊Googledriveダイレクトに入れる方法もあるが、セキュリティ面で推奨できない【テストケースの使用用途（新規プロジェジェクト？保守プロジェクト？回帰テスト？）】　　テスト実行と一気通貫を想定した場合 ... 　◆コーディングによる APIを使って自動テストを実行する想定の例　　　　‐ シフトレフト（テスト対象が完成していない状態で実行させる想定）　　　　　 →仕様書を必要に応じて、データ駆動型にして、画面仕様から組み立てる実装　　　　‐ シフトライト（テスト対象が完成している状態で実行させる想定）　　　　　 →テスト対象をクローリングして、各要素に仕様を当て込む実装　◆MCPによる自動テストを実行する想定の例　　 ‐ AIが理解しやすいような用語、意味を利用する必要あり（曖昧さがあると挙動が変化するため）

テストケースについてモーダル人の作業を支援するといった位置づけが主になります。 - テストケース作成は他のドキュメント作成と比較して、 AI側で連続して推論することとなる為、記載量が少ないです。　*高度なモデルであっても、一度に沢山作成できるといったわけではない為　注意が必要。（ここに夢を見てはダメです）　また、プロンプトによる工夫も必要となります。
　*AIが手を抜くと、 ”同上”、”‥”のような省略を行うケースがあるため、防止が必要。 - 出力して欲しいカラムはプロンプトで定義しておく必要があります。 - 仕様を読み込ませるコンテキスト量とテストケース作成量のバランスを取りながら生成させる必要があります。

テストケースについて API利用 ‐ AIを利用すれば、かなり時短で実装自体に時間はかからないですが、内容の精度を上げるためのプロンプト調整に時間が掛かります。　また、テスト実行自動化と一気通貫で利用することを踏まえた場合、　実装はテスト計画書、テスト設計書に比べると難易度は高いです。 ‐ RAGとしての利用はテキストデータ (JSON、markdown、CSVなど）、
データストア、 NotionDBなど、いくつか工夫を重ねることで可能と思います（筆者はまだ実装中）　*RAGのフォーマットなどは事前に定めておく必要あり ‐ テストケースが重複しないための処理、 RAGとして取得している値を漏らさずにする処理が必要になります。　*重複させないようにするのは困難であるため、意味的重複を排除する必要あり

テストケースについて API利用 ‐ 「テスト観点」のタグ付けを行うと、 AI判断のブレが大きくなるため、 ISO起点でnormal(正常系） /edge（異常系）で分割しておく方が AI側は理解しやすい（テスト観点は何度やってもダメでした）　* ただ、Geminiはなぜか
NoteBookLM上ではテスト観点の概念が分かっている模様（ただし、 Geminiなりにひねり出した感じがする） ‐ 「テキストボックス」などの様々な値が入力できるものについては、「データ駆動」で仕様を落とし込みを行い所定のファイルをキャッシュなりファイルで読み込める状態にしておく方が利便性は高い　 *全てのパラメータ化を行うと肥大化するため、「パラメータ用のテストデータ」ファイルを用意しておく方が望ましい - AIによる自己レビューを実行する場合、スコア化させておくと AIが自己レビューしやすくなります。 ‐ 作成したものを NoteBookLMに入れて、仕様と照らし合わせる荒業も利用可能

テストケース作成についてノートブック型ダイアログ利用 ‐ モーダルよりも作成数は極端に少ないものの、全てエビデンス付きで取得されるため、出力の信頼度が最も高い　ただし、出力したいカラムを必ず指定して、機能などを絞り込む作業が必須 💡 AIを活用することで、テストケース作成を行うメリット
　　‐ 一定のルールに従って、作成させることができ、誤字脱字、コピペミスがない　　 ‐ 他のテストドキュメントと比較して、段階的に出力できるのでレビューが行いやすい 💡 AIを活用することで、テストケース作成を行うデメリット　　‐ 仕様書のフォーマットを定めておく必要があり、準備にも相応の時間が掛かる　　 - 意味的重複されたテストケースが生成されることがある

テストスクリプトについて 💡 テストスクリプト生成にあたり、いくつか決めることがあります。　　 ‐ テスト設計書、仕様書などの作成元とする資料のファイルフォーマット　　 ‐ テスト自動化のスクリプト選定（ Playwright、Selenium　など）
　　 - 作成時の言語の選定【MCPとコーディングによる API利用】　どちらが良さそうかは、実際にチャレンジしてみて考えた方が良いと思います。　◆コーディングによる APIを利用　　　→テスト対象の HTML、JSと仕様書を RAGにしてテストスクリプトを実装させる　◆MCPによる自動テストを実行する想定（テスト実行との一気通貫）　　　‐ MCPで要素を取りながら、テストスクリプトを実装させる（要素取得作業がかなり楽になる）　　　 * ただし、実装が完了していることが条件　　感触として、テストスクリプトを初見で作成するなら、 MCP経由で作成した方が楽かと思います。

テストスクリプトについてモーダル人の作業を支援するといった位置づけが主になります。 - MCP前提だとかなり楽になります。　モーダル単体だと書き慣れている方なら良いですが、　初見でチャレンジされる方は結構面倒です。 - スクリプトを生成するにあたり、生成リストを用意しておくと　かなり楽に管理できます。（途中で迷子にならない）
- プロンプト指示する際には、言語や記載例も用意しておくと良いです。 API利用 - スクリプトの自動生成は PlayWriteなどをLangChainでラッパーを作っておき、　実装を代替させることは可能ですが、そもそものシナリオ検討も行う必要が　あるため、敷居は高めです。 - 作成したいスクリプトを AIを利用してコーディングした方が圧倒的に早いです。 - 出力されるレポートを自前カスタマイズもできます（多少面倒ですが）

テストスクリプトについてノートブック型ダイアログ利用 ‐ 残念ながら NoteBookLMでは記載はできません（将来的には記載できるようになるかもしれませんが） 💡 AIを活用することで、テストケース作成を行うメリット　　‐
MCPを取得することで要素を取得したり、確認するといったこれまでの煩わしい作業から解放　　 ‐ すでにテストスクリプトを書き慣れていれば、修正作業などはかなり便利 💡 AIを活用することで、テストケース作成を行うデメリット　　‐ APIを使った実装を行う場合、相応の時間とコストが掛かる　　 - MCPで操作が難しい部分の実装が必要になる（当然ですが ...）

テスト実行について 💡 テスト実行にあたり、いくつか決めることがあります。　　 ‐ テストケースなどの実行対象とするドキュメント（ CSVが一番わかりやすい）　　 ‐ 実行した結果の管理方法
モーダル ‐ 基本的には MCPを利用したテスト実行となります。　実行しても、操作が思うように動作しないことがよくあります。　（目的を達成する為の手段は選ばずに操作するため）　また、セキュリティテスト、負荷テストを行うことはできません。 💡参考：Operatorで実行した結果 ‐ 20ケースを投げたところ、最初の画面遷移から 5分以上経過しても操作できませんでした。 * ケース数が少なければ、動作するかもしれませんが、現時点では MCPよりはるかに遅いです

テスト実行についてノートブック型ダイアログ利用 ‐ 残念ながら NoteBookLMでは実行はできません API利用 - 自然言語によるの自動実行は PlayWriteなどをLangChainでラッパーを作り、
　実装することは可能ですが、物量も多く敷居は高めです。 - 負荷テスト、クロスブラウザテスト、 APIテスト、　モバイルテストは別途実装が必要となります。 - 出力されるレポートを自前カスタマイズもできます - テスト内容によっては同期／非同期の実装も必要となります。 💡 AIを活用することで、テスト実行を行うメリット　　‐ 自然言語でテスト自動実行が可能 💡 AIを活用することで、テスト実行を行うデメリット　　‐ APIを使った自然言語によるテスト自動化実装を行う場合、相応の時間とコストが掛かる　　 - テスト設計自動化と整合性を合わせながら実装する場合、非常に工数が掛かる

テスト報告書について 💡 テスト報告書を作成するにあたり、いくつか決めることがあります。　　 ‐ テスト結果一覧、BTS　など（CSVが一番わかりやすい）　　 ‐ 報告書のフォーマット（ Markdown、HTMLを推奨）
モーダル ‐ 表形式にまとめるべきもの、文章で作成すべき内容など　いくつかに分割して生成するようにします。 - 不具合分析はポイントを絞り込んだ上で生成する方が望ましい。 - MCPを利用して BTSへ直接分析を問い合わせる方法もあります。 💡参考： ‐ コンテキスト数が多いモデルを利用して、最初に Markdownのガイドラインを　事前に渡しておくことが必要。

テスト報告書について API利用 ‐ 不具合分析については、ステータス毎またはカテゴリ毎に CSVで出力させます。　CSVファイルを出力後に 1チケット毎に安価モデルで簡易分析させた方が　コスト的にも安心かつ、精度が高くなるポイントです。　* 過去のコメントも取得しておくと、無効起票の内容も分析可能
　* 内閣府APIで祝日日を取得して、起票から Closeまでの営業日数計算などを　実装しておくと、営業日ベースの分析も行ってくれます。　出力後は高価なモデルを利用して、包括的な分析をさせることができます。 ‐ テスト計画書、設計書と同様に報告書のフォーマットを作成しておきましょう。 ‐ グラフ作成などは HTMLで埋め込みを行います。　ゾーン分析などの図示が必要なものは SVG形式にするなどの方法があります。

テスト報告書についてノートブック型ダイアログ利用 ‐ 簡易分析はできるものの、見解などの出力が甘いです。　* QAエンジニアの記載するような一歩踏み込んだ分析になりません 💡 AIを活用することで、テスト報告書を作成するメリット　　-
APIを活用すれば実用レベルに限りなく近いものが出力できるようになる　　　* 生成AIにおける効果が最も発揮しやすいため　　 ‐ 生成されたものをレビューする時間も精度が高い為、時間を多く取られることがない 💡 AIを活用することで、テスト報告書を作成するデメリット　　‐ BTSのカラム内容がPJ毎に異なる場合、実装ファイルを分けるか条件分岐処理が必要

他にも活用できたこと Webモーダルから行ったこと ‐ 説明が難しい内容の言語化（抽象度コントロールが行いやすい） ‐ 自身の考えているプロセス、フロー、処理を図示化（フローチャートなど） - 会議の議事録の精査（ただし、元データの RAGに依存するが、Teamsのデータは精度が低い） -
インフラの課題と問題点の分析（ API実装でも対応できそうな内容） - 仕様理解のための整理／壁打ち - 利用頻度が高いプロンプトの定型化 - MCPを利用して直接チケット起票

将来的に必要となるかもしれないポイント 💡 AI思考空間設計　　‐ AIの思考や推論をソフトウェアテストとしてコントロールする手法などが　　　必要になるかもしれない。（高度な依頼を簡易的なプロンプトでは実現が難しい） 💡 ドキュメント品質の担保（既存資産の見直しまたは改善活動）　　‐ AIが理解しやすい品質になっているかどうかを担保するための活動。
💡 AIありきを前提で考える工数算出方法　　‐ このあたりは色々と調査する必要があるかもしれない。これまで PoC的に色々な利用を行ってきている中で、気づいたポイントを記載しておきます。

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

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

More Decks by fumisuke

Other Decks in Technology

Featured

Transcript