Azure DevOps を本格導入する前に dev.azure.com 上でサンドボックス環境を作り、Test Plans でテストケースを作り込んだものの、「このテスト資産を本番環境に移せるのか」「サンドボックスはこの先どう扱えばよいのか」で悩むケースは少なくありません。本記事では、サンドボックスから本番 Azure DevOps へのテストケース移行パターンを整理し、実務でそのまま使える手順と注意点を解説します。
サンドボックスから本番 Azure DevOps への移行でよくある悩み
Azure DevOps を評価する際、多くのチームが dev.azure.com 上に「検証用」「PoC 用」の サンドボックス組織／プロジェクト を作成し、その中で Test Plans や Boards を使ってテストケースやユーザーストーリーを作り込みます。
ところがいざ正式に Azure DevOps を購入・本番運用しようとしたタイミングで、次のような疑問が必ずといってよいほど出てきます。
- サンドボックスで作ったテストケースやテストプランを、本番組織へ 「そのまま」移行できるのか？
- 購入後にサンドボックス側は 削除されてしまわないか？
- テスト実行履歴やレポートはどうなるのか？
結論を先に整理すると次の通りです。
- dev.azure.com 上のサンドボックス組織／プロジェクトは、正式購入後も 自動で削除されません。検証環境として併用可能です。
- サンドボックスから本番環境への テストケース移行は可能 ですが、Azure DevOps に 標準の「ワンクリック移行」機能はありません。Excel、オープンソースツール、サードパーティ製ツールなどを組み合わせて対応します。
- テスト実行履歴や統計情報は原則として そのまま移行できない 前提で設計する必要があります。
ここからは、Azure DevOps のサンドボックスと本番環境の関係を整理しつつ、具体的な移行手段と、「どの規模ならどの方法を選ぶべきか」を詳しく見ていきます。
Azure DevOps のサンドボックスと本番環境の関係
まず押さえておきたいのは、Azure DevOps の「サンドボックス」と「本番環境」は、技術的には同じ Azure DevOps Services（dev.azure.com）の 別組織（Organization）・別プロジェクト にすぎない、という点です。
評価用に作った dev.azure.com 上の組織やプロジェクトは、後から別の本番用組織を作成しても、基本的に 勝手に削除されたり、自動でマージされたりすることはありません。Microsoft Q&A でも、評価用プロジェクトは購入後もそのまま残り、検証用途として使い続けられることが案内されています。
整理すると、よくある構成は次のようになります。
- サンドボックス組織：評価・検証用。テストケースやサンプルデータ、PoC 用のパイプラインなどを自由に試す場所。
- 本番組織：実際のプロジェクト・プロダクトを運用するための正式環境。
本番環境を立ち上げる際は、次のどちらかのパターンで考えることが多いでしょう。
- サンドボックスと別に 新しい組織を作成 し、そこを本番とする。
- 同一組織内に 「検証用プロジェクト」と「本番プロジェクト」 を分ける。
どちらを採るかはガバナンスや運用ポリシー次第ですが、セキュリティ境界やライセンス管理をきっちり分けたい企業では、サンドボックス用と本番用で 組織自体を分ける パターンがよく選ばれます。その場合、テストケース移行は「組織間移行」となり、後述の Migration Tools やサードパーティ製ツールを使うのが現実的です。
何が移せて、何が移せないのかを整理する
テストケース移行を検討するときに最初にやるべきことは、「どの情報をどこまで引き継ぎたいか」を明確にすることです。Azure DevOps でテスト関連のデータは、ざっくり次のように分解できます。
| 要素 | 移行しやすさ | 代表的な移行方法 | 補足 |
|---|---|---|---|
| テストプラン | △ | Migration Tools、サードパーティ | Excel ではプラン構造は持てない。ツールにより階層再現可否が異なる。 |
| テストスイート（静的／クエリベース等） | △ | Migration Tools、サードパーティ、コピー／クローン（同一組織内） | Excel 移行では階層を手作業で作り直す必要がある。 |
| テストケース（手順・期待結果など） | ◯ | Excel／CSV、Migration Tools、サードパーティ | 最も移行しやすい対象。ID や履歴は保持しにくい。 |
| テスト構成（Configurations） | △ | 移行先で再作成、Migration Tools | Excel では移せないため、移行先で事前に定義しておくのが現実的。 |
| テスト変数・共有パラメーター | △ | Migration Tools、サードパーティ | ツールごとにサポート範囲が大きく異なる。 |
| テスト実行結果・履歴 | ✕〜△ | 基本は移行しない。特殊ツールやカスタムスクリプトで部分移行。 | 原則として「旧環境を参照専用で残す」前提で設計する。 |
| 作業項目 ID | ✕ | 新 ID として再採番 | 同じ ID を維持するのはほぼ不可能。元 ID はカスタムフィールドなどで保持する。 |
| 変更履歴・コメント | ✕〜△ | Migration Tools、サードパーティ | 一部ツールは履歴も移行可能だが、完全性や再現性に限界がある。 |
| 添付ファイル | △ | Migration Tools、サードパーティ | ファイルサイズや件数が多い場合は時間がかかる。 |
| リンク（要件・バグ・親子関係など） | △ | Migration Tools、サードパーティ | リンク先も同時移行する必要があるため、設計が重要。 |
この表をもとに、どこまでの情報を「移行すべき本番資産」とみなすかを、チーム内で合意しておくことが重要です。多くの現場では、まずは以下のように割り切るケースが多く見られます。
- 必須で移行したいもの：テストケースの本文（タイトル、ステップ、期待結果）、優先度、担当者、タグなど。
- 可能なら移行したいもの：テストスイート構造、テストプラン、添付、作業項目同士のリンク。
- 割り切って移行しないもの：テスト実行履歴、詳細な変更履歴、コメントスレッド。
主な移行手段の比較（早見表）
Azure DevOps のテストケース移行でよく使われる手段を一覧にしておきます。
| 手段 | 規模感 | メリット | デメリット／制約 | 向いているケース |
|---|---|---|---|---|
| Excel エクスポート／インポート | 〜100〜200 件程度 | 習得しやすい／素早く試せる／追加コスト不要 | ID・履歴・リンクが切れる／スイート階層を手作業で再構成する必要がある。 | 小さめのプロジェクト、PoC からの取り込み、まずは最低限のテストケースだけ移したいとき。 |
| Azure DevOps Migration Tools（OSS） | 数百〜数万件 | テストケースだけでなくプラン／スイートも含めた移行が可能／設定次第でリンクや履歴も再現度高く移せる。 | 初期設定のハードルが高い／Config の理解が必要／ドライランなど検証に時間がかかる。 | 本番稼働中のプロジェクトを別組織にまとめたい、既存プロセスから別プロセスへ移行したいなど、中〜大規模移行。 |
| サードパーティ製ツール（OpsHub など） | 数千〜数十万件 | GUI・サポートあり／テスト結果や履歴を含めた高精度移行に対応する製品もある。 | 多くは有償／製品ごとに機能差が大きい／PoC・トライアルが必須。 | 複数システム間の双方向同期が必要、コンプライアンス要件が厳しく履歴を極力残したい大企業。 |
| コピー／クローン機能（同一組織内） | 少〜中規模 | Azure DevOps 標準機能で完結／利用者にとって分かりやすい。 | 同一組織内のみ／実行履歴はコピーされない／組織をまたいだ移行には使えない。 | 「検証プロジェクト」と「本番プロジェクト」が同じ組織内にある場合の複製。 |
| Test Case Migrator Plus（レガシー） | 小〜中規模 | Excel や Word/MHT からの取り込みに対応する専用ツール。 | 更新が止まっておりサポート対象バージョンが古い／今後を見据えると新規採用は非推奨。 | オンプレ TFS や古い Azure DevOps Server を使っている環境でのスポット利用。 |
この表を見れば分かるように、「小規模なら Excel」「中〜大規模なら Migration Tools かサードパーティ」が基本方針になります。以降は、それぞれの手段をもう少し掘り下げていきます。
Excel エクスポート／インポートで行う小規模移行
テストケースが数十〜百件程度であれば、まず検討したいのが Excel を使った移行 です。Azure Test Plans では、テストケースを CSV や Excel 形式でエクスポートし、編集したのちに再インポートする公式な手順が提供されています。
Excel を使った移行の基本手順
- 移行元でテストケースをエクスポート
- サンドボックス側の Azure DevOps で「Test Plans」を開き、対象のテストスイートを選択します。
- テストケース一覧から、メニューのエクスポート機能（CSV／Excel）を利用してローカルファイルに書き出します。
- もしくは「Boards > Queries」でテストケース用のクエリを作成し、「Open in Excel」で直接 Excel に読み込む方法もあります。
- Azure DevOps Excel アドインで本番プロジェクトに接続
- クライアント PC に Azure DevOps 用の Excel アドイン（Office Integration）をインストールします。
- Excel から「チーム」メニューを開き、本番側の Azure DevOps 組織／プロジェクトにサインインします。
- テストケースとして取り込み可能な形式に整形
- 「Work Item Type」を Test Case に設定し、Title や Area Path、Iteration Path、Assigned To など必要な列を追加します。
- ステップ・期待結果は Azure DevOps のテストステップ形式に合わせて列を構成するか、手動で修正します（ここが一番地味に時間がかかるポイントです）。
- 不要な列や、移行先には存在しないカスタムフィールドは削除しておきます。
- 本番プロジェクトへ Publish（インポート）
- Excel の「Publish」ボタンを押して、本番プロジェクトにテストケースを一括登録します。
- エラーが出た行については、フィールド名や必須項目の不足を確認して修正します。
Excel 移行で押さえておきたいポイント
- ID は引き継がれない：本番側では新しい Work Item ID が採番されます。旧 ID を残したい場合は、「Original ID」などのカスタムフィールドを作成して、Excel から書き戻す運用が現実的です。
- テストスイート階層は手作業で再構築：Excel では階層構造を直接表現できないため、本番側でテストスイートやフォルダーを作り直し、ドラッグ＆ドロップでテストケースを割り当てます。
- テスト構成やテスト変数は移行前に作っておく：Excel では Test Configuration や変数情報を扱えないため、本番プロジェクト側で先に定義しておき、必要に応じてテストケースへ割り当てます。
- 添付ファイルは別途対応：Excel にはファイル添付が含まれないため、重要な添付がある場合は手動で登録し直す、もしくは Migration Tools など別手段の検討が必要です。
Excel 移行の最大の利点は「準備コストの低さ」と「やってみれば流れが分かる」点です。サンプルとして 10 件だけ移してみて、ステップの崩れや文字化けの有無を確認してから本番規模に広げると、トラブルをぐっと減らせます。
Azure DevOps Migration Tools による本格移行
テストケースが数百件を超えてきたり、テストスイートの階層やリンク構造も含めて可能な限り再現したい場合には、コミュニティが提供するオープンソースの Azure DevOps Migration Tools を検討する価値があります。
このツールは .NET ベースのコンソールアプリケーションで、JSON の設定ファイルに従って Azure DevOps のプロジェクト間、さらには組織間で、次のようなデータを移行できるよう設計されています。
- Work Items（テストケースを含む）
- Test Plans / Test Suites（プランとスイート）
- Teams や Area Path、Iteration Path などの構成情報
- リンクや添付ファイル（設定次第）
Migration Tools 導入前のチェックポイント
- PAT（個人用アクセストークン）の発行：移行元・移行先それぞれに対して、必要な権限を持つ PAT を発行します。
- プロセス・フィールドの整合性確認：移行元と移行先で使用しているプロセス（Agile／Scrum／Basic／Inherit など）と、カスタムフィールドの差分を洗い出し、必要なフィールドを事前に作成します。
- ユーザー（ID）マッピング：Assigned To や Created By をどのアカウントに紐付けるか、マッピングルールを決めておきます。
- ネットワークと実行環境：長時間の実行に耐えられるサーバーや仮想マシンを用意し、途中でスリープ・再起動が入らないようにします。
設定ファイル（configuration.json）のポイント
Migration Tools では、どの範囲をどう移すかを JSON ファイルで定義します。典型的には、次のような Processor を組み合わせて利用します。
- WorkItemMigrationConfig：テストケースを含む作業項目を移行。
- TestPlansAndSuitesMigrationConfig：テストプランやスイートの階層を移行。
テストケース移行で特に注意したい設定は以下です。
- WIQL クエリで対象範囲を絞り込む：全テストケースを一度に移行するのではなく、「Area Path」や「タグ」で対象を絞るとトラブル時の切り戻しが容易になります。
- フィールドマッピング：移行元にしかないカスタムフィールドをどう扱うか（新フィールドにマップする／捨てる／コメントに退避する）を明確にします。
- リンク・添付の扱い：リンク先の作業項目も同時に移行するのか、テストケースだけ切り離して移行するのかを決めて設定します。
ドライランと本番実行
Migration Tools を本格利用する際の鉄則は、とにかく ドライラン（テスト実行）をしっかり行う ことです。
- 別のテスト用プロジェクトを用意し、まずは数十件だけ移行してみる。
- タイトル・ステップ・リンク・担当者・タグなどが期待通り再現されているか確認する。
- 問題があれば Config を修正し、再度ドライランを繰り返す。
ある程度満足できる再現性が担保できたら、メンテナンスウィンドウを確保したうえで本番移行を実施します。並行して更新されると不整合の原因になるため、「移行期間中はサンドボックス側のテストケース更新を凍結する」というルールを事前に周知しておくと安心です。
サードパーティ製ツールを検討すべきケース
さらに要求が厳しくなり、例えば次のような条件がある場合には、サードパーティ製の有償ツール（例：OpsHub Integration Manager など）を検討した方がトータルコストが下がることもあります。
- テストケースだけでなく、テスト結果（パス／失敗履歴）や履歴情報もできる限り保持したい。
- Azure DevOps だけでなく、Jira や他のテスト管理ツールとも 双方向同期 したい。
- 自分たちだけで Migration Tools の設定・運用を回すのは難しく、ベンダーサポート付き で実行したい。
ツール選定の際には、次の観点で比較するのがおすすめです。
| 観点 | チェック内容 |
|---|---|
| 対応範囲 | テストケースだけか、テスト結果・履歴・添付・リンク・パイプライン等も含めて移行・同期できるか。 |
| サポート体制 | PoC や本番移行時に、ベンダーがどこまで伴走してくれるか（設定レビュー、当日サポートなど）。 |
| ライセンス体系 | ユーザー数・プロジェクト数・移行量など、どの指標に対して課金されるか。 |
| ロールバック方法 | 移行に失敗した場合にどこまで戻せるか、スナップショットやバックアップ戦略はどうなっているか。 |
サードパーティ製ツールは一見高価に見えますが、「自前で Migration Tools を調べながら何度もやり直す工数」や、「失敗時のリスク」を考えると、結果的に安くつくケースもあります。本番リリースがビジネス的にクリティカルなタイミングと重なる場合は、積極的に検討してよい選択肢です。
コピー／クローン機能で同一組織内の複製を行う
もしサンドボックスと本番が同一の Azure DevOps 組織内にある場合は、標準の コピー／クローン機能 を活用することで、よりシンプルにテストケースを複製できます。
代表的なパターンは次の通りです。
- テストプラン全体をコピーして別のプロジェクトに複製する。
- 特定のテストスイートだけを別プランにコピーする。
- 一部のテストケースだけをコピー／クローンして再利用する。
この方法のメリットは、移行というより「複製」に近いため、ユーザーにとって操作感が分かりやすく、ツールやスクリプトの準備が不要な点です。ただし、コピー／クローンでは テスト実行履歴は複製されない こと、組織をまたいだ移行には使えないことを覚えておきましょう。
Test Case Migrator Plus が「レガシー」とされる理由
Microsoft 公式ブログでも紹介された Test Case Migrator Plus は、かつてテストケースを Excel や MHT／Word から Team Foundation Server（TFS）や Azure DevOps Server に取り込むためのツールとして公開されました。
現在も GitHub でソースコードが公開されており、一部環境では活用されていますが、サポート対象は主に TFS 2017〜2019 や Azure DevOps Server 2019 といったオンプレ環境です。最新の Azure DevOps Services（クラウド）を前提にした新規導入で、これから積極的に採用するツールとは言い難く、
- 既に導入済みのオンプレ TFS からのスポット移行
- どうしても既存の Word／MHT ドキュメントを取り込みたいケース
など、特殊な要件がある場合の選択肢として位置づけるのが現実的です。サンドボックスから本番 Azure DevOps Services への移行という文脈では、基本的には Excel または Migration Tools／サードパーティ を優先して検討するとよいでしょう。
テスト実行履歴はどう扱うべきか
テストケースの移行で最も「割り切り」が必要になるのが、テスト実行結果（履歴） の扱いです。多くのツールや手順は、テストケース定義の移行を主目的としており、過去の実行履歴まで完全に移すことは難しいのが現実です。
一部のサードパーティ製ツールやカスタムスクリプトでは、REST API を使ってテストラン情報を生成し直すことで、過去の結果を「擬似的に再現」することもできますが、実装コストに見合うかどうかは慎重な判断が必要です。
多くの現場では、次のようなポリシーで運用することが多いです。
- テストケースは本番環境に移行し、以降の実行は本番側でのみ行う。
- サンドボックス側は 参照専用（読み取り専用） として残し、過去の結果を確認したいときだけ開く。
- 必要に応じて、重要なテストレポートだけを PDF や Excel としてエクスポートし、成果物として保管する。
監査やコンプライアンス要件が厳しい場合は、テスト結果を本番側に一部再現するのか、サンドボックス側をどの程度の期間保持するのかを、セキュリティ部門・品質保証部門と一緒に方針化しておくと安心です。
実務で使える移行チェックリスト
ここまでの内容を踏まえ、現場でそのまま流用しやすい 移行チェックリスト として整理してみます。
- 移行範囲を決める
- 対象プロジェクト／テストプラン／スイートを一覧化する。
- 移行したいテストケースの条件（Area、タグ、作成日など）を決め、クエリに落とし込む。
- 添付・リンク・テスト構成・テスト変数をどこまで引き継ぐかを決める。
- 移行先のプロセスとフィールドを整える
- 本番組織にプロジェクトを作成し、使用するプロセス（Agile／Scrum／Basic／Inherit）を確定する。
- 必要なカスタムフィールドや状態（ステータス）があれば先に作成しておく。
- Area Path・Iteration Path を、本番プロジェクトの運用方針に合わせて設計しておく。
- テスト構成・テスト変数を先に作る
- ブラウザから Test Plan の設定を開き、Configurations や Test Variables を本番側に作成する。
- サンドボックス側の構成をそのままコピーするのか、本番用に整理・統合するのかを決める。
- 権限・認証情報を準備する
- 移行作業を行うユーザー／サービスアカウントに、必要なプロジェクト権限が付与されているか確認する。
- Azure DevOps Migration Tools や API を使う場合は、Scope を適切に絞った PAT を発行し、安全な場所に保管する。
- 移行方式を選定する
- テストケースが 100 件未満であれば、まずは Excel 移行を試してみる。
- 100 件を超え、スイート階層やリンクの再現が重要であれば、Migration Tools またはサードパーティ製ツールを検討する。
- 同一組織内の複製で済む場合は、コピー／クローン機能で足りないかを確認する。
- ドライラン（試し移行）を実施する
- 本番プロジェクトとは別に「移行検証用プロジェクト」を用意する。
- そこへ 10〜20 件だけ移してみて、ステップの崩れ・文字化け・リンク切れがないかを確認する。
- 必要に応じて Excel の列定義や Migration Tools の Config を調整する。
- 本番移行ウィンドウと凍結ルールを決める
- 「この日時以降はサンドボックス側でテストケースを更新しない」という期限を決め、関係者に周知する。
- 移行中に何か問題があった場合のロールバック手順（例：本番側で作成されたテストケースを一度削除するなど）を決めておく。
- 検証と旧環境の扱いを決める
- 移行後、本番側のテストケース件数・タグ・担当者・スイート構造をサンドボックス側と突合する。
- サンドボックス組織／プロジェクトはすぐには消さず、一定期間は読み取り専用で残す。
- 最終的に削除する場合は、必要なレポートや成果物を事前にエクスポートして保管する。
シナリオ別：おすすめの移行パターン
小規模チーム（テストケース 50 件程度）の場合
数十件のテストケースしかなく、サンドボックスでの実行履歴もそれほど重視しない場合は、次のパターンがシンプルです。
- Excel でテストケースをエクスポートし、本番プロジェクトにインポート。
- 本番側でテストスイートやテストプランを新規に作成し、テストケースをドラッグ＆ドロップで割り当て。
- サンドボックス側は 1〜2 か月だけ残し、特に問題がなければ整理（削除）する。
この規模で Migration Tools を使うと「ツールの勉強コスト」の方が大きくなりがちなので、まずは Excel による移行から検討することをおすすめします。
中規模プロジェクト（テストケース数百件、複数のテストプランが存在）
テストケースが数百件以上あり、テストスイートの階層やリンク構造も本番側にできるだけ再現したい場合は、Azure DevOps Migration Tools を中心に設計するのが現実的です。
- Migration Tools で Test Plans / Suites と Work Items をあわせて移行する。
- まずは 1 プロジェクト分の一部範囲だけを対象にドライランを行い、フィールド・リンク・添付の再現性を確認する。
- 問題がなければ、残りのテストケースと関連作業項目も範囲を広げながら段階的に移行する。
このシナリオでは「一気に全部移す」のではなく、「プロジェクト単位」「プラン単位」など、段階を分けた移行計画にすることでリスクを小さくできます。
大規模・ミッションクリティカルなシステムの場合
数千〜数万件のテストケースがあり、テスト結果や履歴もビジネス的な意味を持つようなシステム（金融・医療・公共など）では、サードパーティ製ツールの導入や、専門ベンダーへの相談も視野に入れるべきです。
- Migration Tools だけではカバーしきれない要件（履歴・テスト結果の再現など）を整理し、ツールベンダーに PoC を依頼する。
- PoC の中で、実際のサンドボックスデータを一部使ったデモ移行を実施し、期待値とのギャップを確認する。
- 移行作業自体も、ベンダーの支援を受けながら実施する（立会い・事前リハーサルなど）。
ここまでの規模になると、移行は単なる技術作業ではなく「プロジェクト」として扱うべきテーマになります。テストチームだけで抱え込まず、インフラチームや情報システム部門も巻き込んだ計画を立てましょう。
よくある質問（FAQ）
Q. サンドボックスのプロジェクトは本番環境を作ったら消えてしまいますか？
A. いいえ、消えません。dev.azure.com 上のサンドボックス組織／プロジェクトは、正式購入後も自動削除されず、そのまま残ります。検証用として併用したり、過去のテスト実行結果を参照する目的で保持しておくことができます。
Q. サンドボックスの組織をそのまま「本番扱い」にしてしまうのはダメですか？
A. 技術的には可能ですが、検証用途で作った組織は権限設計や命名ルールが緩く、本番運用に耐えないケースも多いため、本番用に新しい組織／プロジェクトを作り直す ことをおすすめします。そのうえで、テストケースを移行した方が、長期的にきれいな構成を保ちやすくなります。
Q. テストケースの「実行履歴」も含めて本番環境に移したいのですが？
A. Excel や Migration Tools では、テスト実行履歴の完全移行は基本的に想定されていません。REST API とスクリプトを組み合わせれば、擬似的に履歴を再現することも不可能ではありませんが、工数とメリットを慎重に比較する必要があります。コンプライアンス上どうしても必要な場合は、履歴移行をサポートするサードパーティ製ツールやベンダーに相談するのが近道です。
Q. 移行後にサンドボックス側のテストケースを更新してしまったらどうなりますか？
A. 移行後にサンドボックス側を更新すると、本番側と内容が乖離してしまい、どちらが「正」なのか分からなくなります。移行ウィンドウを決めたうえで、「この時点以降はサンドボックス側でテストケースを変更しない」というルールを必ず設け、関係者に周知しておきましょう。
Q. ユーザー（担当者）のアカウント名がサンドボックスと本番で違う場合はどうすべきですか？
A. Migration Tools やサードパーティ製ツールを使う場合は、ユーザーのマッピングテーブルを用意して、「旧アカウント → 新アカウント」に変換する設定を行うのが一般的です。Excel で移行する場合は、あらかじめ Excel 上で担当者列を新アカウント名に書き換えてからインポートするようにします。
まとめ：サンドボックスは残しつつ、テストケースだけ賢く移行する
サンドボックスから本番 Azure DevOps へのテストケース移行は、一見複雑そうに見えますが、ポイントを押さえればそれほど怖い作業ではありません。本記事の内容を最後にもう一度、要点に絞ってまとめます。
- dev.azure.com 上のサンドボックス組織／プロジェクトは、正式購入後も自動削除されず、検証や参照用として そのまま残しておける。
- テストケースの移行自体は Excel／Migration Tools／サードパーティ製ツール などで実現可能だが、標準のワンクリック移行は存在しない。
- テスト実行履歴の完全移行は難しいため、「テストケース定義だけを本番側に移し、履歴はサンドボックス側を参照用に残す」という割り切りが現実的な落としどころになりやすい。
- 移行計画では、移行範囲の明確化・移行先プロジェクトの整備・ドライラン・凍結期間の設定 の 4 点を意識することで、トラブルを大きく減らせる。
これから Azure DevOps を本番導入するチームにとって、サンドボックスはとても貴重な「実験場」です。その資産を無駄にしないためにも、本記事を参考に、テストケースを賢く移行しつつ、サンドボックスを安全な検証環境として活かし続けてください。
コメント