Azure Test Plans

解決する課題

リリース前の品質確認で、「どのテストを誰が実施し、どこまで通ったのか」を表計算ファイルやメールで散発的に管理すると、進捗も合否も追えなくなります。Azure Test Plans は、テストの計画・実行・結果記録をひとつの場所に集約し、要件やバグと紐づけて品質を見える化します。

• 手動テストのケース・手順・期待結果を体系立てて管理し、実行のたびに合否を記録したい
• 各リリースでどのテストが通り、どれが未実施・失敗かを進捗として追跡したい
• 探索的にアプリを触りながら見つけた不具合を、再現手順やスクリーンショット付きで素早く起票したい
• 要件（作業項目）からテストケース、テスト結果、バグまでを双方向にたどれる追跡可能性を確保したい
• ステークホルダーからのフィードバックを構造化して集め、開発に取り込みたい

主要概念と用語

• テスト計画（Test Plan）: あるリリースやスプリントで実施するテストをまとめる最上位の単位。期間や対象を表す
• テストスイート（Test Suite）: テストケースをグループ化する入れ物。静的スイート、要件ベーススイート、クエリベーススイートの 3 種類がある
• テストケース（Test Case）: 個々のテスト。手順（ステップ）と各ステップの期待結果を持つ作業項目として管理される
• 共有ステップ（Shared Steps）: 複数のテストケースで共通する手順を部品化し、再利用できるようにしたもの
• 共有パラメーター（Shared Parameters）: 同じ手順を異なる入力値で繰り返す「データ駆動テスト」のための値セット
• テスト実行（Test Run）/ 結果（Test Result）: テストケースを実行した記録。各ステップに合格・不合格などの結果を残す
• 構成（Configuration）: ブラウザーや OS などの実行環境の組み合わせ。同じテストを複数環境で実施し分けられる
• 探索的テスト（Exploratory Testing）: 事前のスクリプトに頼らず操作しながら検証する手法。Test & Feedback 拡張で支援される
• Test & Feedback 拡張: ブラウザー拡張機能。操作の記録、スクリーンショット注釈、バグ起票、フィードバック収集を行う

仕様・制限・クォータ

• 提供形態は **Azure DevOps Services（クラウド）**と **Azure DevOps Server（オンプレミス）**の両方がある
• 利用には **Basic + Test Plans のアクセスレベル（ライセンス）**が必要。テスト計画の作成や実行管理を行うユーザーに割り当てる
• Test & Feedback 拡張を使うフィードバックの提供（バグ起票やコメント）は、より軽いアクセスでも参加できる場合がある
• テストケースは Azure Boards の作業項目として保存されるため、作業項目のフィールドやリンク機構をそのまま使える
• 手動テストの実行はブラウザー上の Web ランナーで行うのが基本。手順ごとに合否を記録し、コメントやスクリーンショットを添付できる
• ライセンスの具体的な割り当て条件や付帯機能は変動するため、計画時は対象組織の最新のライセンス情報を確認する

内部の仕組み

Azure Test Plans のデータは Azure Boards の作業項目モデルの上に構築されています。テストケースは「Test Case」という種類の作業項目で、手順・期待結果はその中に格納されます。テストスイートとテスト計画もそれぞれ専用の項目として表現され、互いにリンクで関連づけられます。

要件ベーススイートは、Boards のバックログ項目（ユーザーストーリーや機能）に直接ひも付く形で作られます。これにより「この要件を検証するテストはどれか」「そのテストは通ったか」を要件側からたどれます。クエリベーススイートは作業項目クエリの結果を動的に集めるため、条件に合うテストケースを自動でまとめられます。

手動テストを実行すると、各ケースに対するテスト結果（Test Result）が生成され、テスト計画の進捗に集計されます。探索的テストでは Test & Feedback 拡張がブラウザー操作を記録し、起票したバグに操作ログやスクリーンショット、画面録画を自動で添付できます。Azure Pipelines で実行した自動テストの結果も同じ仕組みに集約でき、手動・自動を横断して品質を追跡できます。

設計パターン / ベストプラクティス

• 要件ベーススイートを基本にする: テストを要件にひも付け、カバレッジと追跡可能性を最初から確保する
• 共有ステップで手順を部品化: ログインなど共通操作を共有ステップ化し、変更を 1 か所で反映できるようにする
• 共有パラメーターでデータ駆動: 同じ手順を複数の入力値で回し、ケースの重複を避ける
• 構成で環境を分離: 対応ブラウザーや OS を構成として定義し、同じテストを環境ごとに実施・集計する
• 手動と自動を役割分担: 探索的・受け入れ寄りは手動、回帰テストは自動（Pipelines）に寄せ、結果を同じ場所に集約する
• 探索的テストで初期品質を底上げ: スクリプト化前の段階で Test & Feedback を使い、再現手順付きのバグを早期に集める

運用・監視

• テスト計画の進捗チャートで、実行済み・合格・不合格・未実施の比率を追い、リリース可否の判断材料にする
• 失敗したテストはバグ作業項目に変換し、再現手順や添付を引き継いで開発側へ受け渡す
• 構成や担当者ごとに結果を絞り込み、どの環境・誰の担当で詰まっているかを把握する
• Pipelines の自動テスト結果を取り込み、手動・自動を横断したテスト動向をダッシュボードで可視化する
• 計画やスイートが肥大化したら、クエリベーススイートで条件管理に切り替え、メンテナンスの手間を抑える

コスト

課金はおおむねユーザーに割り当てるアクセスレベル（ライセンス）単位です。テスト計画の作成・管理・実行を行うユーザーには Basic + Test Plans の有償アクセスが要り、単純なフィードバック提供だけならより軽い参加で済む場合があります。利用人数を実態に合わせて見直すことが主なコスト最適化になります。

セキュリティ

• アクセスは Microsoft Entra ID と Azure DevOps の権限で制御し、テスト計画の作成・編集・実行権限を最小化する
• テスト手順や結果に本番の機微データを直接書かないよう注意し、必要なら参照のみにとどめる
• 探索的テストのスクリーンショットや画面録画に秘匿情報が写り込まないよう扱いに気をつける
• 外部のステークホルダーをフィードバックに招く場合は、閲覧・起票の範囲を絞った権限で参加させる

関連サービス・比較

テストケースは Azure Boards の作業項目として保存され、Azure Pipelines の自動テスト結果とも統合されます。Test Plans は「手動・探索的テストの計画と実行管理」に特化し、Pipelines は「テストの自動実行」を担う、という役割分担で理解すると整理しやすくなります。

ハンズオン / CLI例

# Azure DevOps CLI 拡張を追加し、組織・プロジェクトの既定を設定
az extension add --name azure-devops
az devops configure --defaults \
  organization=https://dev.azure.com/myorg \
  project=demo-project

# テストケースは作業項目として作成する（種類: Test Case）
az boards work-item create \
  --title "ログイン: 正しい資格情報で成功する" \
  --type "Test Case" \
  --output table

# テスト計画はブラウザー（Test Plans ハブ）で作成・実行するのが基本
# CLI からは関連する作業項目やバグの管理を補助的に行う
az boards work-item create \
  --title "ログイン失敗時のエラー表示が出ない" \
  --type "Bug" \
  --output table

# 作成済みのテスト関連作業項目を確認
az boards work-item show --id 123 --output table