CRM に回帰テストが必要な理由
本番稼働後も、CRM は変わり続けます。自社のチームが何も変更していなくてもです。Salesforce と Microsoft は、すべての顧客のプラットフォームを更新します。ほとんどの変更は改善です。一部はページ、既定の設定、機能の動作を変え、ときには業務が頼りにしているものを壊してしまうこともあります。
回帰テストが答える問いは 1 つです。業務部門が本番稼働時に承認したものは、今も動くか？ 新しい UAT ではありません。最も重要なプロセスに絞った短く集中的な確認で、変更がユーザーに届く前に、その仕事を知る人が行います。
自社のリリースにも同じ確認が必要です。新しい連携、見積の新しい項目、ケースの振り分けの変更。どれも以前は動いていたものに影響する可能性があります。
Salesforce：年 3 回のリリース
Salesforce には年 3 回のメジャーリリースがあります：Spring、Summer、Winter です。Winter リリースは秋に提供され、翌年の番号が付きます。すべての組織が、Salesforce が事前に公開する日程でアップグレードされます。
- Sandbox プレビュー。プレビューインスタンス上の Sandbox には、本番環境の数週間前に新しいリリースが適用されます。これがテストの期間です。Salesforce はリリースごとに、どのインスタンスがプレビューの対象か、Sandbox をプレビューに残すには何をすべきかを公開しています。更新によって Sandbox がプレビューに入ったり外れたりすることがあるため、早めに確認してください。
- リリースノート。使っているクラウドと機能について読みます。自動的に有効になるもの、ユーザーが作業するページの見た目を変えるものを探します。
- リリース更新。一部の変更は、適用される日付とともに設定画面で告知されます。本番環境で驚かないよう、その日付の前に Sandbox でテストしてください。
つまり Salesforce の場合、リズムはあらかじめ決まっています。各リリースのプレビュー期間に回帰テストラウンドを 1 回、年 3 回です。
UAT Studio ではプロジェクトの CRM として Salesforce を選びます。リリースの約 2 か月前から、プロジェクトページに Coming CRM releases が表示され、Sandbox プレビューの日付、本番の日付、リリースノートへのリンクがわかります。Salesforce がこれらの日付を変更することもあるため、リリースノートを確認してください。
Dynamics 365：年間を通じたアップデート
Microsoft は、Dynamics 365 の変更を年 2 回のリリースウェーブにまとめることをやめました。新機能や変更は年間を通じて順次提供されます。リリース計画は 2026 年 10 月にアーカイブされ、今後の予定は Microsoft のロードマップ aka.ms/AIatWorkRoadmap に掲載されています。
つまり、テストを計画する基準となる年に一度の大きな節目は、もうありません。変更はより小さな単位で、より頻繁に届きます。大きなリリースを待つ方法はもう通用せず、変更のたびにテストするのは負担が大きすぎます。
決まったリズムを選ぶ
答えは、Microsoft がその間に何をリリースしても、決まったリズムで回帰テストラウンドを行うことです。
- CRM が業務の中心にある、多くのアプリや機能を使っている、新機能を頻繁に有効にしている場合は毎月。
- 自社の変更が少ない安定した構成なら四半期ごと。
- 自社の変更が本番稼働する前や、Microsoft の変更が主要なプロセスのいずれかに明らかに影響する場合は追加のラウンド。
1 年分の日程をテスターのカレンダーに入れておきます。決まったリズムは、何かあるたびに計画するラウンドよりも続けやすいものです。
各ラウンドの前に
- Microsoft のロードマップと、Microsoft 365 管理センターの管理者向けメッセージを読み、どの変更が自社のプロセスに影響するかを書き留めます。
- プレビューの機能は、ユーザーに届く前に、まずサンドボックス環境で試します。
- テストするサンドボックスが、本番環境と同じバージョン、同じソリューションであることを確認します。
UAT Studio ではプロジェクトの CRM として Dynamics 365 を選び、各ラウンドは本番稼働時のプロジェクトまたは前回のラウンドから Start a regression round で始めます。
UAT Studio ではSetup の Check the Dynamics 365 updates で Every quarter または Every month を選びます。プロジェクトページに現在の期間とロードマップへのリンクが表示され、管理者には期間ごとに 1 通、期間が始まる 2 週間前にメールが届きます。
再テストするものを選ぶ
回帰テストラウンドは、すべてをもう一度テストする場ではありません。次の順序で選びます。
- Must のテストケース。毎日動かなければならないもの：見積の作成、リードの取引の開始、ケースの振り分け、承認。これらは毎ラウンドテストします。
- 変更が影響するもの。自社のプロセスの一覧を横に置いて、リリースノートやロードマップを読みます。見積に関する変更なら、見積のテストケースを、Should や Could のものも含めてテストします。
- 連携と自動化。ERP、ウェブサイト、メールとの連携、そしてバックグラウンドで動くフロー。これらは気づかないうちに壊れるため、意図的にテストします。
- 時間があればShould のテストケース。
次に、前回のラウンド以降に自社のチームが変更したものを確認します。自社で構築したもので、プラットフォームの変更と一緒にテストされていないものは、すべてラウンドの対象に含めます。
重要なものの短いリストを作る
業務部門が 1 日たりとも欠かせない 10～20 のプロセスを、一度書き出しておきます。それがすべての回帰テストラウンドの中心になります。このリストは半年ごとにプロセスオーナーと見直し、自社で大きな変更をした後にも見直します。
UAT Studio ではRelease readiness アドオンがあれば、Review the release で Salesforce のリリースや Dynamics 365 の更新が影響するテストケースを理由とともに示し、まだカバーされていない部分のテストケースを提案し、必須の更新を日付とともに一覧にします。回帰テストラウンドには、Must のテストケース、残すことにした影響を受けるテストケース、承認した新しいテストケースだけが入ります。ラウンドでの Fail は、どの変更に関係するかを示します。月額 €99。Plan & billing から追加できます。
テストケースを再利用する
手元にある最良の回帰テストは、本番稼働時の UAT のテストケース一式です。業務部門が承認した内容を、ステップ、テストデータ、期待結果とともに正確に表しています。ラウンドのたびに新しく書かないでください。
- 本番稼働後もテストケースを優先度とともに 1 か所に残しておきます。
- 自社のプロセスが変わったらテストケースを更新し、次のラウンドで本番稼働時の CRM ではなく、今の CRM をテストできるようにします。
- 各ラウンドの前にテストデータを確認します。Sandbox の更新や本番環境のコピーによって、テストケースが使うレコードが削除・変更されることがあります。
- 本番環境で見つかった重大な課題ごとにテストケースを追加し、次回は見つけられるようにします。
業務テスターがたどれるテストケースは、ここで手間をかける価値があります。何度も繰り返し再利用されるからです。業務テスターにわかるテストケースの書き方をご覧ください。
UAT Studio ではStart a regression round で、元にするプロジェクトのテストケースを、ステップ、テストデータ、期待結果とともにコピーします。どれを含めるかを選びます：Must and Should、Only Must、または All test cases in scope。優先度のないテストケースは Should として扱われます。新しいプロジェクトにはグループと設定が引き継がれ、テスターは Setup で招待します。何かがでっち上げられたり変更されたりすることはありません。
誰が、どれくらいテストするか
誰が
回帰テストラウンドに必要な人数は UAT より少なくて済みますが、それでも業務部門から選ぶべきです。プロセスごとに 1～2 人のキーユーザーに依頼します。毎日その仕事をしていて、何かおかしいとすぐに気づく人です。CRM 管理者はラウンドを準備し、バックグラウンドで動くものをテストしますが、唯一のテスターになるべきではありません。
ラウンドごとに同じ人にテストしてもらいます。回を重ねるごとに速くなり、新しいテスターなら見逃す小さな変化にも気づきます。
期間
- 準備：変更内容を読み、テストケースを選び、テストデータを確認するのに 1～2 日。
- テスト：テスターごとに数時間。毎月のラウンドなら 1～2 日に分散し、変更の多い Salesforce のリリースなら最大 1 週間。
- 修正と再テスト：見つかった課題のために、変更が本番環境に届く前に数日を確保します。
Salesforce の場合、これをプレビュー期間内に収める必要があります。最後の週ではなく、期間の早い段階で始めてください。
見つかったことの記録
課題は UAT と同じように登録します：ステップ、期待していたこと、代わりに起きたこと、スクリーンショット、レコードへのリンク。毎日 CRM チームとトリアージします。プラットフォームが原因の課題は、まずリリースノートやロードマップを確認します。多くの場合、調整できる設定のある既知の変更です。
UAT Studio では各ラウンドにリリース、ビルド、環境が記録されるため、go/no-go レポートで何をテストしたかがわかります。修正後は、ダッシュボードの Start round 2 で Failed and blocked only を選ぶと、うまくいかなかったものだけを再テストできます。前のラウンドの結果は残ります。
本番環境の前のサインオフ
回帰テストラウンドも UAT と同じく判断で終わりますが、より短くなります。終了基準は一度合意し、毎ラウンド使います。
- Must のテストケースがすべて合格している。
- Critical の課題が未解決で残っていない。
- 未解決の High の課題にはすべて、業務部門が受け入れる回避策があるか、変更が本番環境に届く前に修正される。
各プロセスのオーナーが自分の担当部分についてサインオフします：承認、条件付き承認、却下のいずれかです。Salesforce のリリースではアップグレードを止められないため、却下とは、本番の日付までの修正または回避策と、ユーザーへの連絡を意味します。自社の変更の場合、却下とはその変更を待たせることを意味します。
すべてのラウンドの結果を残しておきます。1 年後には、各変更の後に何をテストし、誰が承認したかの明確な記録になります。判断の準備方法については、go/no-go 判定をご覧ください。
UAT Studio では回帰テストラウンドはそれ自体が 1 つのプロジェクトで、そのリリースを Release として持つため、go/no-go レポートでどの CRM リリースについてのものかがわかります。プロセスオーナーはグループごとにサインオフし、サインオフはそのラウンドに属します。
無料で使える
CRM 本番稼働のための UAT チェックリストは、回帰テストラウンドにも使えます。無料の Excel ファイルです。プラットフォームごとの情報は、Salesforce UAT と Dynamics 365 UAT をご覧ください。
Salesforce は Salesforce, Inc. の商標です。Microsoft と Dynamics 365 は Microsoft グループ企業の商標です。UAT Studio は Salesforce および Microsoft と提携しておらず、その承認も受けていません。