こんにちは。とあるQAチームに所属するbun913と申します。
私は、普段 SDET(Software Development Engineer in Test)として、テスト自動化や品質向上に取り組んでおり、自動テストの作成だけでなく、手動テストによる品質向上にも力を入れています。
私たちのQAチームでは、AIやMCPサーバーと言われる技術を活用して従来のテスト工程を効率化しています。今回は6ヶ月以内に開始して、ある程度形になってきたAI・MCPを活用したテスト工程の改善について、イメージしやすいように実際のリポジトリのディレクトリ構造などを添えてご紹介したいと思います。
※ この取り組みは他のメンバーと協力して進めているもので、断りを入れた上で書ける範囲で具体的に記載しています。
この記事のまとめ・何が嬉しいのか？
AIによる効率化や生産性の向上は急務です。一方で、マニュアルテストによるバグの検出数も依然として重要であり、マニュアルテストの有無で年間だと内部発見バグに数百件の差があると感じています。
AIにほとんどを任せられる世界線もいつか来るかもしれませんが、これまでの工程にAIを組み込むことによる、目に見える改善も重要です。今回は、私たちのチームが実際に取り組んでいる内容をご紹介します。
- 目指している姿
- まずはQAチームでテスト工程を統一し、AIやMCPを活用して効率化を図る（今回の記事はここまでが狙いです）
- 具体的な取り組み
- プロジェクトによらないドメイン知識やテストの観点を一箇所にまとめる
- 統一されたテスト手法を活用して、特に「チェック」の観点で「何をテストするか」をAIに整理させる
- MCPを活用して単に情報を取得するだけでなく、テストケース作成などをAIに支援させる
これらの取り組みを行うことで、以下のような効果を感じています。
- 他のQAの人と一緒に一箇所でテスト観点などを整理できる
- これまでの成果物をGitで管理しているので、次のAI活用などにもすぐ活用できる
- MCPを活用することで、テストケースの作成などにかかる工数が大幅に削減でき、QAが「探索的なテスト」や自動テストにもっと時間を使えるようになってきた
それでは、具体的な取り組みについて見ていきましょう。
今回お話しする範囲（工程）について
さて、実際にQAチームやテスト技術者がテストを行う際には以下のような項目があります。
この中で、今回の記事では「テスト分析」と「テスト設計」の工程におけるAI・MCP活用について紹介します。
リポジトリの準備と構成
私たちはテストに関する設計や分析をする際に、1つの Git リポジトリを作成して、そこに知識やノウハウを蓄積しています。このリポジトリは、テストに関する情報を一元管理するための重要な場所となっています。
ディレクトリの構成は以下のようになっています。
test-analysis-repo/
├── .rulesync/ # AI用のルール・プロンプト設定
├── knowledge/ # プロジェクト共通の知識ベース
│ ├── domain/ # ドメイン知識
│ ├── past_failures/ # 過去のインシデント情報
│ ├── products/ # プロダクト情報
│ └── qa_perspectives/ # テストカテゴリ・観点
├── projects/ # プロジェクト固有のディレクトリ
│ └── project_A/
│ ├── specs/ # 要求・仕様ドキュメント
│ └── artifacts/ # テスト分析の成果物
└── scripts/ # 便利スクリプト
各ディレクトリの役割
.rulesync/
- Claude Code などのAIツールで利用するルールやプロンプトを管理しています
- 後で説明するゆもつよメソッドという手法のテスト分析手順やフォーマットなどを定義しています
- rulesync を活用することで、ツールが変わっても変更を最小にしつつ、他のAIツールを使って同じ手順を実行してどちらのモデルの方がよかったかなどの比較もしやすくなります
knowledge/ - プロジェクト共通の知識ベース
このディレクトリには、特定のプロジェクトに依存しない共通の知識を格納しています。AIがテスト分析を行う際に、コンテキストとして参照されます。
-
domain/- プロダクト固有のドメイン知識や、関連するマイクロサービスの情報をコンパクトにまとめています
- 箇条書きで「サービスが提供する機能」や「私たちのサービスで利用している場所」など、QAやチームが当たり前に理解している情報を簡単に整理します
-
past_failures/- 過去のインシデントの情報などを表形式で簡単にまとめています
- このテスト分析だけでなく、他のリポジトリやCIなどから利用できるように1箇所に集約しています
-
products/- 自チームで管理しているプロダクトに関する情報を整理しています
- 例えばプロダクトが解決したい課題や、保有する機能などを箇条書きやmermaid.jsを活用して簡潔に整理しています
- 機能面や仕様に関する情報が多いイメージです
-
qa_perspectives/- テストカテゴリやテスト観点をまとめています
- 簡単にいうと、どういった機能に対して「どういう点を気をつけないといけないよ」ということを表形式でまとめています
- 例えば「ユーザー情報を更新する」という機能に対しても、バリデーションやエラーハンドリングの他にも「どの画面に情報が反映されているべきか。ユーザープロフィールだけでなく、設定画面やダッシュボードにも反映されるべき」といった観点を整理します
- 後で説明するゆもつよメソッドで使用する「テストカテゴリ」の定義などを格納しています
- テストカテゴリやテスト観点をまとめています
projects/ - プロジェクト固有のディレクトリ
-
specs/- 要求や仕様を整理したドキュメントを格納します
- ここには既にある情報を格納するだけのイメージです
-
artifacts/- ここにテスト分析のステップごとの成果物を格納します
- 機能項目、テストカテゴリと仕様項目のマッピングなどをバージョン管理します
scripts/
-
npm run newなどのコマンドで特定のproject用のディレクトリの作成などを行えるような便利スクリプトを用意しています - 将来的には例えば、過去のインシデント情報の自動更新などの機能を追加していく予定です
テストにおける「チェック」と「探索」
私たちがテストを行う際、大きく分けて2つの分類があります：
-
チェック: 要求や仕様が満たされているかを確認する活動
- 要求を仕様が満たしているか
- 仕様を実際のアプリケーションが満たしているか
- このような観点で、定められた内容をチェックしていきます
-
探索: 仕様書に書かれていない問題を発見する活動
- 実際にアプリケーションを触りながら、予期しない動作やバグを見つけます
- What if（これを使って、あれをしたらどうなるんだろう）という視点でアプリケーションを探索する感じです
- QAの経験や勘が活きやすい部分です
私たちのチームでは、まず チェックの工程をAIを活用して効率化することから始めています。
チェックの工程を効率化することで、QAが「探索的なテスト」や自動テストに時間を使えるようになるからです。実際に、テストケースの作成などにかかる工数が大幅に削減でき、バグの早期発見にもつながっています。
テスト分析における「ゆもつよメソッド」の活用
私たちのチームでは、テスト分析において 個人によるテスト品質のズレを極力少なくする ため、「ゆもつよメソッド」という手法を参考にしています。
この手法では、以下のようなステップを踏んでテスト分析を進めます：
- 機能項目の整理: リリース内容を大きな機能単位で分類
- テストカテゴリの定義: テストするべき観点（カテゴリ）を事前に定義
- 仕様項目のマッピング: 機能項目とテストカテゴリをマッピングして、具体的な仕様項目を洗い出す
私たちはこれを参考にしていますが、厳密には独自の解釈やステップ、AI用にちょっとアレンジしている部分があると思います。今回は詳細は割愛させていただきます。
具体的には、.rulesync/ 配下にゆもつよメソッドの各ステップをルールファイルとして定義し、AIと 1ステップずつのレビューを通しながら、小さくアウトプットとレビューを繰り返していく 形で進めています。
AIに指示するためのルール定義の具体例
以下は、AIに指示するためのルール定義の具体例です。小さくステップを分けて定義して、AIに小さく作業してもらいます。
overview.md - 全体の方針
プロジェクトの目標やワークフローの全体像を定義しています。例えば：
- 体系的なテスト分析を行うこと
- テスト分析からテストケース作成までを効率化すること
- 分析ではゆもつよメソッドを使用し、mermaid.jsやテーブル形式で成果物を出力すること
testAnalysis.md - テスト分析の詳細手順
ゆもつよメソッドの具体的なステップを定義しています。具体的なイメージとしては以下のような内容です：
## 全体プロセス
### 1. モデル作成
- **参照ファイル**: 仕様書
- **論理的機能構造要素**:
- 入力調整: 入力に対する処理（入力検証など）
- 変換: システムの主要な役割（計算ロジックなど）
- 格納: データの保存、取得
- 支援: エラー処理、状態遷移
- **成果物**: 各機能のモデル図（mermaid.js形式）
### 2. 機能一覧の作成
- **目的**: 仕様書に散在する情報を機能単位で整理
- **作業手順**: テスト対象の機能を一覧化
※ 各ステップにおける成果物のフォーマット、命名規則、参考にするべきファイルなどの定義なども記載しています
アレンジ・実践で培ってきたポイント:
私の場合、テスト分析開始のかなり早い段階で「この機能に関してはフローが複雑だから、整理しながらフロー図を作ろう」や「ここの機能は状態遷移図を作っておこうか」などと個々の機能に対して具体的な図解などを支援させることもあります。
従来であれば、より詳細に仕様を小さく整理していく中で図を作ることもあったのですが、この段階でAIと対話しながら図を使って整理しておくことで、後のステップがスムーズに進みますし、コンテキストを思い出させるのにも役立つと感じています。
テスト設計工程におけるMCP・AIの活用
テスト分析工程では「何をテストするか」を決定しました。次のテスト設計工程では、「じゃあどうテストするか」を具体化していきます。
ここでは、MCP（Model Context Protocol）という技術を活用することで、テストケースの作成や管理を大幅に効率化しています。
MCPとは
MCPは、AIツールが外部サービスと連携するための仕組みです。
これまでは、テスト分析の成果物をもとに、手作業でTestRailやZephyrといったテストマネジメントツールにテストケースを登録していく必要がありました。しかし、MCPを活用することで、自然言語で指示するだけで、これらのツールを操作できるようになります。
こちらは以前のブログから引用した画像ですが、以下のように口頭で「このテスト分析結果を元に小さく分けてテストケースを作っていこう！」というような指示を出すことで、手動でテストケースを作成する作業を大幅に効率化できます。
- 私:
APIテストのケースとして @05_test_analysis.md を元に小さくテストケースを作ろう。 - 私：
まずは OAuth2.0 の認証フローの部分からだね。試しにバリデーションについてテストケースを作ってみてよ
具体的なMCPサーバーの例
例えば、以下のようなMCPサーバーを利用することができます。私が作成したツールを広げたいわけではありませんが、以下は実際に私が活用しているMCPサーバーです。最低でも、脆弱性対応などは行って新バージョンを公開できるように維持しています。
- mcp-testrail: TestRailとの連携
- mcp-zephyr: Zephyrとの連携
これらを使うことで、AIに対して「テスト分析の成果物をもとに、TestRailにテストケースを作成して」と指示するだけで、以下のような作業を自動化できます：
- テストケースの作成（タイトル、ステップ、期待結果など）
- テストスイートの構成
- テスト結果の記録
AIは、テスト分析で作成した仕様項目やテストカテゴリをもとに、適切なテストケースの構造を理解し、丁寧にテストステップを作成してくれます。
注意が必要なのは、テスト分析の結果をそのままAIに渡して、「これを元にテストケースを作って」と指示すると、具体的にどのようにテストするのか不明瞭になったり、テストケースが適切に生成されないことが多いです。
テストケースを作らせる際には、「ユーザーの権限チェック」などのような粒度ではなく「一般ユーザーは管理画面にアクセスできない」「管理者は全ての機能にアクセスできる」といった「どうやってそれを確かめるか」というレベルに落とし込んで指示することが重要です。
最後に
今回は、私たちのQAチームが実際に取り組んでいるAI・MCP活用の工程について紹介しました。
今後もより良い仕組みや利用方法があれば、ぜひ共有していきたいと思います。
最後までお読みいただき、ありがとうございました。
Discussion