AIにおけるソフトウェアテスト_ver1.00

Transcript

1. AIにおけるソフトウェアテスト 猫おじさんの PoC実験結果 (2025/4)
2. 最初にお伝えしたいこと ・ 全体的に人の作業は支援できるが、 AIで全て「0 -> 100」を実現には至らない。 　 全量のAIで行うにはまだ遠いものの 　 1年前と比較すると飛躍的にできることのバリエーションが増えた。 　　LLMの台頭によりこれまでのテスト実行自動化を除き、 　　現時点で「0 ->100」を完全実現できたのはテスト結果報告書のみ 　　＊企業文化によっては、実現できないかもしれないが、最も「 0 ->100」に近い認識 ・ AI活用をイチから進めるには、相応の時間 /コストが必要 　　夢をみず、現実的にできることから着手する方が望ましい 　　実験的なPoCも非常に時間が掛かるので、今回はその見解も踏まえている。 ・ AIが出力されたものはレビューに時間が掛かり、一意に出力されない 　　デメリットとして認識しておくこと。むしろ、活用するならその覚悟が必要。 　　当たり前として認識し、周りにも周知しておく方が良い。
3. はじめに ・　AIを活用したソフトウェアテストに関するものとして記載しています。 　「2025年4月」時点の更新版となります。 ・　以下については、あらかじめご了承ください。 　　‐　あくまで実用してみた結果などを踏まえている為、 　　　 ベストプラクティスはご自身の企業およびプロジェクトによって異なります 　　‐　新しい生成AIモデル、アプリ層のサービスが提供された場合、 　　　 これらの記載されている前提が大きく変化する可能性があります 　　‐　モデル等の所感はあくまで個人の所感です。 　　　 個人個人に見合った最適なモデルを見つけて頂くことをお勧めします - 今回、API利用についてはOpenAIのモデルをサンプリングしています。 　　　 他のモデルと性能変化がある点についてはご承知おきください - 単体テストにおける活用は様々な記事が出ている為、そちらをご参照ください
4. 目次 　　- 生成AIを利用する上で意識すべき点 　　- テスト計画書について 　　- テスト設計書について 　　- レビューについて 　　- テストケースについて 　　- テストスクリプトについて 　　- テスト実行について 　　- テスト報告書について
5. 生成AIを活用する上で意識すべき点 　AIを日々利用し続ける事のメリット 　　　- 毎日会話することで AIの苦手な点、得意な点を理解できるようになります。 　　　　　以下のような整理が個人でも出来るようになります（あくまで個人の感想です） 　　　　 　　　- 利用に慣れると、他の Closedモデルとの差異が理解できるようになり、 　　　 使い分けがクリアに行えるようになります。 　　　- モデルの特性を知ることで、ハルシネーションのポイントも 　　　 理解できるようになってきます。 　　　　Gemini2.5　…コンテキスト数が多く、 ZeroShotは得意だが、 　　　　　　　　　　　ソースコード記述は得意ではない（できないわけではない） 　　　　　　　　　　　コンテキストの軌道修正がしづらい。 　ChatGPT o1 Pro　…コンテキスト数は少ないが、エラーが発生しない 　　　　　　　　　　　 無難なソースコードを記載をすることが多い
6. 生成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
7. 生成AIを活用する上で意識すべき点 　IDEのルール設定、sysytemプロンプトとhuman(user)プロンプト 　　- IDEのルール＆MDC設定： コード品質・一貫性を機械的に担保する（静的解析・整形・リントなど） コード整形ルール、型チェック設定 　　- system prompt　　　 ： LLM の“人格”・振る舞い・制約を規定し、会話全体を統制する 会話全体のフォーマットを絶対に守らせたい場合に利用 　　- human (user) prompt ： ユーザが実際にやらせたいタスク・質問を記述。その瞬間だけ必要な指示
8. 参考資料(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 が存在すると、すべ てのリクエストで全文注入（非推奨）
9. テスト計画書について 💡 テスト計画書を作成するにあたり、いくつか決めることがあります。 　　‐ テスト計画書の作成元とする資料のファイルフォーマット 　　 ‐ 作成時の出力方法（可読性の意味で markdownを推奨） モーダル 人の作業を支援するといった位置づけが主になります。 ‐ IDEのモーダル作成であれば、自動でドキュメントに入力できるため、 コピー作業などの雑務的な手間がなくなりますが、出力量が少ないです。 出力量の参考： 1000行のプロジェクト計画書サンプル（ markdown）を 　　　　　　　基にテスト計画書を依頼した場合 (ゼロショットの記載依頼 ) 　　　　　　Gemini2.5かつcursor利用 ：約250行 　　　　　　Claude3.7sonetかつWebモーダル利用：約400行 　　　　　　o1ProかつWebモーダル利用 ：約270行
10. テスト計画書について API利用 ‐ AIを利用すれば、かなり時短で実装自体に時間はかからないですが、 内容の精度を上げるためのプロンプト調整に時間が掛かります。 　また、図などを Mermaid形式で指定した場合、図が思った形で 出力されないことが多いです（ 1/4ぐらいの確率で成功する程度） ‐ こちらも人の作業を支援する位置づけとはなりますが、 モーダルよりも精度を上げることが可能です。 ‐ Mermaid形式で出力を検討している場合、表の箇所のみ HTMLにすることで、 表の崩れを抑えることは可能です。 　ただし、問題点として、 Markdownの改変がしづらくなる可能性があります。 ‐ 筆者はLangchainを利用して実装しています。
11. テスト計画書について ノートブック型 ダイアログ利用 ‐ 一部作成はできるがテスト戦略なり、テスト方針のたたき台には利用可能です。 　ただし、言葉は同じで意味が異なるものを取り扱う場合は注意してください。 根拠についてもエビデンスはあるが、抽象度が高すぎるような指定の場合、 　出力されない（回答を拒否される）ため、注意が必要です。 💡 AIを活用することで、テスト計画書を作成するメリット 　　‐ イントロダクションを考えてくれる（冒頭の記載を考えるが面倒） 　　 ‐ とりあえず、APIを利用すると自分が記述すべき分量が圧倒的に減る 💡 AIを活用することで、テスト計画書を作成するデメリット 　　‐ テスト計画書における各章の説明準備工数は必要 　　　（記載しなくても書いてもらえるが、記載しておく方が望ましい） 　　 - APIをコーディングする場合、プロンプトの微調整が必要
12. テスト設計書について 💡 テスト設計書を作成するにあたり、いくつか決めることがあります。 　　 ‐ テスト計画書、要件定義などの作成元とする資料のファイルフォーマット 　　 ‐ 作成時の出力方法（可読性の意味で markdownを推奨） モーダル 人の作業を支援するといった位置づけが主になります。 ‐ IDEのモーダル作成であれば、自動でドキュメントに入力できるため、 コピー作業などの雑務的な手間がなくなりますが、出力量が少ないです。 💡参考： 　 表形式で出力がテスト計画書より多くなる為、安価なモデルは避けて 　 表形式を崩さずに出力できる高価なモデルを利用することをお勧めします 　 読み込ませるファイル数が多い場合、 Gemini2.5などのコンテキスト量が 　 多いモデルの利用を検討してください。
13. テスト設計書について API利用 ‐ こちらも人の作業を支援する位置づけとはなりますが、 モーダルよりも精度を上げることが可能です ‐ 実装自体に時間はかからないですが、内容の精度を上げるための 　プロンプト調整に時間が掛かります ‐ どうしてもテスト観点を加えたい場合、 Geminiは理解できるケースが 　ありながらも、 ISO/IEC25010ベース、 AIが理解しやすい形になどする方が 　望ましいです。ポイントは AIが理解できないものを入れないことです。 - AIの回答履歴を要約して履歴をトークンに含めつつ AIに回答させる必要が 　あるため、トークンのキャッシュ、メモリ管理が必要となる場合があります。 ‐ 筆者はLangchainを利用して実装しています
14. テスト設計書について ノートブック型 ダイアログ利用 ‐ 一部作成はできます。 インフラなどを鑑みたテスト環境など、たたき台としては有用です。 　表形式で出力するものなどは非常に見づらくなる点は注意が必要です。 機能毎の詳細な出力を行うように指示することが必要です。 💡 AIを活用することで、テスト設計書を作成するメリット 　　‐ イントロダクションを考えてくれる（冒頭の記載を考えるが面倒） 　　 ‐ とりあえず、APIを利用すると自分が記述すべき分量が圧倒的に減る 💡 AIを活用することで、テスト設計書を作成するデメリット 　　‐ 記載にあたっての抽象化レベルのコントロールが必要 　　 - 記載内容が細かい場合はトークン管理が必要
15. レビューについて 💡 レビューを行うにあたり、いくつか決めることがあります。 　　 ‐ レビュー対象元の収集 　　 ‐ 出力方法の検討（可読性の意味で markdownを推奨） モーダル 人の作業を支援するといった位置づけが主になります。 ‐ 画像、文章などいずれかをレビューのインプット対象とするが、 　レビューを行う為のガイドラインなどは事前に準備を行い、ガイドラインを 　含めたレビューを行うことで、一貫性があるレビューを行うことができます。 💡参考： 　 レビュー報告用のフォーマットを事前に用意して結果を出力できる形に 　 しておくとスムーズな出力ができ、統一感がある形となります。 　 レビュー対象のファイル数が多い場合、 Gemini2.5などのコンテキスト量が 　 多いモデルの利用を検討してください。
16. レビューについて API利用 ‐ レビューガイドラインをプロンプトに入れて、具体例を出した上で 　指摘を行う方が高い効果を得られやすいです。 　＊具体例がない状態でレビューを行うと、プロジェクトの状況を把握していない 　　指摘が挙がってくるので注意が必要です。 　　（例：手動テスト前提だが、テスト自動化の管理方法がない　など） ‐ 通常APIでは安価なモデルを利用するのが一般的ですが、 　安価なモデルでは複雑な思考に耐えられない為、安価なモデル以外の 　利用をお勧めします。 ‐ 思考を追うような段階的なレビューを順次行う方が AI側で思考の整理が 　行いやすいので、多段的なステップを踏ませるようなレビューの方が良いです - レビューを行った内容に対して、さらにループ処理を行うと 　レビュー精度があがります。 　（指摘も増える傾向にあるが、意味的重複削除処理は必要）
17. レビューについて ノートブック型 ダイアログ利用 ‐ レビューはできるものの、包括的なレビューを行うには不向きです。 　ただ、ピンポイントレビューには一定の有効性はあるため、 　範囲を絞り込んだ形で簡易レビューには利用できます。 💡 AIを活用することで、レビューを行うメリット 　　‐ 自身のレビューのプラス αとして活用（抜けている視点などを補ってくれる） 　　 ‐ 指示すれば、報告書形式で仕上げてくれる為、レビュー結果をフィードバックしやすい 💡 AIを活用することで、レビューを行うデメリット 　　‐ レビュー対象の体裁を事前に整える必要あり（必要に応じて画像や Mermaid記法にするなど） 　　 - レビュー対象のコンテキスト量が多い場合、かなり手間が掛かる
18. テストケースについて 💡 テストケース作成を行うにあたり、いくつか決めることがあります。 　　 ‐ テスト設計書、仕様書などの作成元とする資料のファイルフォーマット 　　 ‐ 作成時の出力方法（可読性の意味で csvを推奨：Excel化やスプシの転用も容易） 　　　＊Googledriveダイレクトに入れる方法もあるが、セキュリティ面で推奨できない 【テストケースの使用用途（新規プロジェジェクト？保守プロジェクト？回帰テスト？）】 　　テスト実行と一気通貫を想定した場合 ... 　◆コーディングによる APIを使って自動テストを実行する想定の例 　　　　‐ シフトレフト（テスト対象が完成していない状態で実行させる想定） 　　　　　 →仕様書を必要に応じて、データ駆動型にして、画面仕様から組み立てる実装 　　　　‐ シフトライト（テスト対象が完成している状態で実行させる想定） 　　　　　 →テスト対象をクローリングして、各要素に仕様を当て込む実装 　◆MCPによる自動テストを実行する想定の例 　　 ‐ AIが理解しやすいような用語、意味を利用する必要あり（曖昧さがあると挙動が変化するため）
19. テストケースについて モーダル 人の作業を支援するといった位置づけが主になります。 - テストケース作成は他のドキュメント作成と比較して、 AI側で連続して推論することとなる為、記載量が少ないです。 　*高度なモデルであっても、一度に沢山作成できるといったわけではない為 　 注意が必要。（ここに夢を見てはダメです） 　また、プロンプトによる工夫も必要となります。 　*AIが手を抜くと、 ”同上”、”‥”のような省略を行うケースがあるため、 防止が必要。 - 出力して欲しいカラムはプロンプトで定義しておく必要があります。 - 仕様を読み込ませるコンテキスト量とテストケース作成量のバランスを 取りながら生成させる必要があります。
20. テストケースについて API利用 ‐ AIを利用すれば、かなり時短で実装自体に時間はかからないですが、 内容の精度を上げるためのプロンプト調整に時間が掛かります。 　また、テスト実行自動化と一気通貫で利用することを踏まえた場合、 　実装はテスト計画書、テスト設計書に比べると難易度は高いです。 ‐ RAGとしての利用はテキストデータ (JSON、markdown、CSVなど）、 データストア、 NotionDBなど、いくつか工夫を重ねることで可能と 思います（筆者はまだ実装中） 　*RAGのフォーマットなどは事前に定めておく必要あり ‐ テストケースが重複しないための処理、 RAGとして取得している値を 漏らさずにする処理が必要になります。 　*重複させないようにするのは困難であるため、意味的重複を排除する必要あり
21. テストケースについて API利用 ‐ 「テスト観点」のタグ付けを行うと、 AI判断のブレが大きくなるため、 ISO起点でnormal(正常系） /edge（異常系）で分割しておく方が AI側は理解しやすい（テスト観点は何度やってもダメでした） 　* ただ、Geminiはなぜか NoteBookLM上ではテスト観点の概念が 分かっている模様（ただし、 Geminiなりにひねり出した感じがする） ‐ 「テキストボックス」などの様々な値が入力できるものについては、 「データ駆動」で仕様を落とし込みを行い所定のファイルを キャッシュなりファイルで読み込める状態にしておく方が利便性は高い 　 *全てのパラメータ化を行うと肥大化するため、 「パラメータ用のテストデータ」ファイルを用意しておく方が望ましい - AIによる自己レビューを実行する場合、スコア化させておくと AIが自己レビューしやすくなります。 ‐ 作成したものを NoteBookLMに入れて、仕様と照らし合わせる荒業も利用可能
22. テストケース作成について ノートブック型 ダイアログ利用 ‐ モーダルよりも作成数は極端に少ないものの、 全てエビデンス付きで取得されるため、出力の信頼度が最も高い 　 ただし、出力したいカラムを必ず指定して、機能などを絞り込む作業が必須 💡 AIを活用することで、テストケース作成を行うメリット 　　‐ 一定のルールに従って、作成させることができ、誤字脱字、コピペミスがない 　　 ‐ 他のテストドキュメントと比較して、段階的に出力できるのでレビューが行いやすい 💡 AIを活用することで、テストケース作成を行うデメリット 　　‐ 仕様書のフォーマットを定めておく必要があり、準備にも相応の時間が掛かる 　　 - 意味的重複されたテストケースが生成されることがある
23. テストスクリプトについて 💡 テストスクリプト生成にあたり、いくつか決めることがあります。 　　 ‐ テスト設計書、仕様書などの作成元とする資料のファイルフォーマット 　　 ‐ テスト自動化のスクリプト選定（ Playwright、Selenium　など） 　　 - 作成時の言語の選定 【MCPとコーディングによる API利用】 　どちらが良さそうかは、実際にチャレンジしてみて考えた方が良いと思います。 　◆コーディングによる APIを利用 　　　→テスト対象の HTML、JSと仕様書を RAGにしてテストスクリプトを実装させる 　◆MCPによる自動テストを実行する想定（テスト実行との一気通貫） 　　　‐ MCPで要素を取りながら、テストスクリプトを実装させる（要素取得作業がかなり楽になる） 　　　 * ただし、実装が完了していることが条件 　　感触として、テストスクリプトを初見で作成するなら、 MCP経由で作成した方が楽かと思います。
24. テストスクリプトについて モーダル 人の作業を支援するといった位置づけが主になります。 - MCP前提だとかなり楽になります。 　モーダル単体だと書き慣れている方なら良いですが、 　初見でチャレンジされる方は結構面倒です。 - スクリプトを生成するにあたり、生成リストを用意しておくと 　かなり楽に管理できます。（途中で迷子にならない） - プロンプト指示する際には、言語や記載例も用意しておくと良いです。 API利用 - スクリプトの自動生成は PlayWriteなどをLangChainでラッパーを作っておき、 　実装を代替させることは可能ですが、そもそものシナリオ検討も行う必要が 　あるため、敷居は高めです。 - 作成したいスクリプトを AIを利用してコーディングした方が圧倒的に早いです。 - 出力されるレポートを自前カスタマイズもできます（多少面倒ですが）
25. テストスクリプトについて ノートブック型 ダイアログ利用 ‐ 残念ながら NoteBookLMでは記載はできません （将来的には記載できるようになるかもしれませんが） 💡 AIを活用することで、テストケース作成を行うメリット 　　‐ MCPを取得することで要素を取得したり、確認するといったこれまでの煩わしい作業から解放 　　 ‐ すでにテストスクリプトを書き慣れていれば、修正作業などはかなり便利 💡 AIを活用することで、テストケース作成を行うデメリット 　　‐ APIを使った実装を行う場合、相応の時間とコストが掛かる 　　 - MCPで操作が難しい部分の実装が必要になる（当然ですが ...）
26. テスト実行について 💡 テスト実行にあたり、いくつか決めることがあります。 　　 ‐ テストケースなどの実行対象とするドキュメント（ CSVが一番わかりやすい） 　　 ‐ 実行した結果の管理方法 モーダル ‐ 基本的には MCPを利用したテスト実行となります。 　実行しても、操作が思うように動作しないことがよくあります。 　（目的を達成する為の手段は選ばずに操作するため） 　また、セキュリティテスト、負荷テストを行うことはできません。 💡参考：Operatorで実行した結果 ‐ 20ケースを投げたところ、最初の画面遷移から 5分以上経過しても 操作できませんでした。 * ケース数が少なければ、動作するかもしれませんが、 現時点では MCPよりはるかに遅いです
27. テスト実行について ノートブック型 ダイアログ利用 ‐ 残念ながら NoteBookLMでは実行はできません API利用 - 自然言語によるの自動実行は PlayWriteなどをLangChainでラッパーを作り、 　実装することは可能ですが、物量も多く敷居は高めです。 - 負荷テスト、クロスブラウザテスト、 APIテスト、 　モバイルテストは別途実装が必要となります。 - 出力されるレポートを自前カスタマイズもできます - テスト内容によっては同期／非同期の実装も必要となります。 💡 AIを活用することで、テスト実行を行うメリット 　　‐ 自然言語でテスト自動実行が可能 💡 AIを活用することで、テスト実行を行うデメリット 　　‐ APIを使った自然言語によるテスト自動化実装を行う場合、相応の時間とコストが掛かる 　　 - テスト設計自動化と整合性を合わせながら実装する場合、非常に工数が掛かる
28. テスト報告書について 💡 テスト報告書を作成するにあたり、いくつか決めることがあります。 　　 ‐ テスト結果一覧、BTS　など（CSVが一番わかりやすい） 　　 ‐ 報告書のフォーマット（ Markdown、HTMLを推奨） モーダル ‐ 表形式にまとめるべきもの、文章で作成すべき内容など 　いくつかに分割して生成するようにします。 - 不具合分析はポイントを絞り込んだ上で生成する方が望ましい。 - MCPを利用して BTSへ直接分析を問い合わせる方法もあります。 💡参考： ‐ コンテキスト数が多いモデルを利用して、最初に Markdownのガイドラインを 　事前に渡しておくことが必要。
29. テスト報告書について API利用 ‐ 不具合分析については、ステータス毎またはカテゴリ毎に CSVで出力させます。 　CSVファイルを出力後に 1チケット毎に安価モデルで簡易分析させた方が 　コスト的にも安心かつ、精度が高くなるポイントです。 　* 過去のコメントも取得しておくと、無効起票の内容も分析可能 　* 内閣府APIで祝日日を取得して、起票から Closeまでの営業日数計算などを 　 実装しておくと、営業日ベースの分析も行ってくれます。 　出力後は高価なモデルを利用して、包括的な分析をさせることができます。 ‐ テスト計画書、設計書と同様に報告書のフォーマットを作成しておきましょう。 ‐ グラフ作成などは HTMLで埋め込みを行います。 　ゾーン分析などの図示が必要なものは SVG形式にするなどの方法があります。
30. テスト報告書について ノートブック型 ダイアログ利用 ‐ 簡易分析はできるものの、見解などの出力が甘いです。 　* QAエンジニアの記載するような一歩踏み込んだ分析になりません 💡 AIを活用することで、テスト報告書を作成するメリット 　　- APIを活用すれば実用レベルに限りなく近いものが出力できるようになる 　　　* 生成AIにおける効果が最も発揮しやすいため 　　 ‐ 生成されたものをレビューする時間も精度が高い為、時間を多く取られることがない 💡 AIを活用することで、テスト報告書を作成するデメリット 　　‐ BTSのカラム内容がPJ毎に異なる場合、実装ファイルを分けるか条件分岐処理が必要
31. 他にも活用できたこと Webモーダルから行ったこと ‐ 説明が難しい内容の言語化（抽象度コントロールが行いやすい） ‐ 自身の考えているプロセス、フロー、処理を図示化（フローチャートなど） - 会議の議事録の精査（ただし、元データの RAGに依存するが、Teamsのデータは精度が低い） - インフラの課題と問題点の分析（ API実装でも対応できそうな内容） - 仕様理解のための整理／壁打ち - 利用頻度が高いプロンプトの定型化 - MCPを利用して直接チケット起票
32. 将来的に必要となるかもしれないポイント 💡 AI思考空間設計 　　‐ AIの思考や推論をソフトウェアテストとしてコントロールする手法などが 　　　必要になるかもしれない。（高度な依頼を簡易的なプロンプトでは実現が難しい） 💡 ドキュメント品質の担保（既存資産の見直しまたは改善活動） 　　‐ AIが理解しやすい品質になっているかどうかを担保するための活動。 💡 AIありきを前提で考える工数算出方法 　　‐ このあたりは色々と調査する必要があるかもしれない。 これまで PoC的に色々な利用を行ってきている中で、気づいたポイントを記載しておきます。