Salesforce UAT：実践ガイド

Salesforce で UAT が必要なとき

ユーザー受け入れテストが答える問いは 1 つです。このバージョンの Salesforce で、業務部門は仕事ができるか？ 本番環境に届く前に、実際にその仕事をする人が、自分の言葉でテストします。UAT が必要なのは次のタイミングです。

• 本番稼働。初めての Sales Cloud や Service Cloud、または他の CRM からの移行。
• 新しいクラウドや大きな変更。Sales Cloud に加えて Service Cloud を導入する、CPQ、ERP との新しい連携、ケースの新しい振り分け方法など。
• Salesforce の各リリース。Salesforce のリリースは年 3 回、Spring、Summer、Winter です。Winter リリースは秋に提供され、翌年の番号が付きます。自分では何も変更していなくても、リリースのたびに組織の動作が変わる可能性があります。
• Sandbox プレビュー。プレビューインスタンス上の Sandbox には、本番環境の数週間前に新しいリリースが適用されます。これがテストの期間です。Salesforce はリリースごとに、どのインスタンスがプレビューの対象か、Sandbox をプレビューに残すには何をすべきかを公開しています。更新によって Sandbox がプレビューに入ったり外れたりすることがあるため、早めに確認してください。

本番稼働には完全な UAT が必要です。リリースには、最も重要なプロセスに絞った短い回帰テストが必要です。詳しくは本番稼働後をご覧ください。

Sandbox

本番環境では決してテストしないでください。Salesforce の Sandbox には 4 種類あり、そのうち 2 種類が UAT に適しています。

更新を計画する

更新すると、Sandbox の中身はすべて本番環境の新しいコピーに置き換わります。Sandbox の種類ごとに更新の最短間隔があり、Full Sandbox の間隔が最も長くなっています。そのため、次のように計画してください。

• 更新は UAT の前に行い、UAT 中には決して行わないでください。次に Sandbox を更新できる時期を確認してください。
• 更新後に、リリースを Sandbox にデプロイしてください。Sandbox にしか存在しなかった作業は失われます。
• 更新後の手順を実施します。連携と指定ログイン情報の接続先を本番環境ではなくテストシステムに変更し、実行すべきでないスケジュール済みジョブを停止します。
• メールの送信可能性を確認します。新規作成または更新した Sandbox は、システムメールしか送信しません。Web-to-リードの返信、承認、ケースのメールにはそれ以上の設定が必要ですが、Full Sandbox には取引先責任者の実際のメールアドレスが含まれています。設定を開放する前に、テスト用のアドレスに置き換えてください。

テストデータ

データの準備ができていないと、テスターは何時間も無駄にします。最初のテスト日の前に準備してください。

• テストする顧客の種類ごとに、適切な所有者、地域、レコードタイプを持つ取引先と取引先責任者。
• 商品と価格表。商品を別の価格表に追加するには、先に標準価格表で価格を設定する必要があります。各営業チームの価格表が有効になっていることを確認してください。
• 作業に使う未完了のレコード：さまざまなフェーズの商談、未解決のケース、エンタイトルメントをテストする場合はマイルストンが近いケース。
• 避けられる場合は実際の個人データを使わないこと。Full Sandbox はすべてをコピーするため、テスターが見る必要のないデータはマスキングまたは匿名化してください。

プロファイルと権限セットごとのユーザー

UAT では、各ロールが自分の仕事をこなせること、そして自分の仕事しかできないことを証明します。テストするプロファイル、ロール、権限セットの組み合わせごとに、営業担当者、営業マネージャー、サービス担当者といったテストユーザーを作成します。テスターごとに専用のユーザーを用意し、2 人が同時に同じユーザーで作業することがないようにします。

更新後、Salesforce はすべてのユーザー名に Sandbox 名を、すべてのユーザーのメールアドレスに .invalid を付加します。各テストユーザーのメールアドレスをテスターが読めるアドレスに設定してください。そうしないと、パスワードのリセットや承認のメールがどこにも届きません。

他のユーザーとしてログインを使うと、管理者は別のユーザーの視点で Salesforce を確認できます。テスターが報告した問題を確認するのに便利な方法です。テストそのものでは、テスターは自分のテストユーザーを使います。そうすることで、プロファイルと権限セットが正しいことを確かめられます。

Sandbox についてテスターに伝えること

• Sandbox のアドレス。アドレスには Sandbox 名が含まれます。または test.salesforce.com からサインインします。Salesforce の通常のログインページでは本番環境が開きます。
• Sandbox 名で終わるユーザー名と、パスワードの受け取り方。
• データはテストデータであること。何をしても実際の顧客には届かず、表示される内容も最新ではありません。
• サインインできないときの連絡先。午前中を無駄にする前に連絡できるようにします。

UAT Studio ではテスターごとに Test role と Test account が割り当てられ、テストの上部に Log in as … として表示されます。Notes for testers には、Sandbox のアドレス、テスト用メールボックス、問い合わせ先を記載します。

ユーザーストーリーとプロセスからテストケースを作る

Salesforce のオブジェクトからではなく、業務のプロセスから始めます。Salesforce の UAT の大部分は、次の 2 つのプロセスでカバーできます。

• リードから入金（Lead to Cash）。リードが Web-to-リードで登録され、割り当てられて取引が開始されます。商談に価格表から商品を追加し、見積を作成して承認を受け、商談が成立すると、注文や契約が次のチームやシステムに渡ります。
• ケース管理。ケースがメール-to-ケースやポータルから登録され、適切なキューや担当者に振り分けられ、エンタイトルメントとマイルストンに沿って進み、ナレッジ記事で解決され、必要に応じてエスカレーションされ、クローズされます。

各プロセスを、1 つの業務シナリオごとのテストケースに分割します（例：既存の取引先でリードの取引を開始する）。そのうえで、対象範囲のすべてのユーザーストーリーに少なくとも 1 つのテストケースがあることを確認します。

業務テスターにわかるステップ

各ステップは、操作と期待結果としてテスターの言葉で書きます。必要な箇所にはテストデータを添えます。ステップが合格したかどうかを、テスターが推測しなければならない状況は避けてください。

優先度とリスク

すべてのテストケースが同じように重要なわけではありません。それぞれに Must、Should、Could を付けます。Must は、見積の作成やケースの振り分けなど、初日から動かなければならないものです。さらにリスク、つまり本番稼働後にうまくいかなかった場合の損失を加えます。テスターは Must で高リスクのものから始めるため、時間が足りなくなっても重要なテストは完了します。

うまくいかないケースも加えてください。必須項目が空のまま、上限を超える値引き、本来見えてはいけないレコードが見えてしまうユーザーなどです。

UAT Studio ではPriority と Risk の列を含む Excel からテストケースを取り込むか、テンプレートライブラリ（すべての有料プランに追加できるアドオン）の Salesforce スクリプトから始められます。テスターには Must のテストケースが最初に表示されます。

テスター

毎日その仕事をしている人を選びます。営業担当者、サービス担当者、そして承認、売上予測、レポートを担うそのマネージャーです。Salesforce を使っているすべてのチームと国からテスターを選んでください。プロセスや価格表がそれぞれ異なるためです。

必要な時間

時間はチーム単位ではなくテスターごとに依頼し、そのマネージャーの合意を得てください。各テスターがどれだけの作業量かわかるように、スクリプトを計画します。修正後の再テストの時間も確保してください。電話対応や顧客訪問を続けながらでは、テスターはテストを終えられません。

キックオフ

まず短いキックオフを行います。なぜそのテストが重要か、Sandbox へのサインイン方法、結果の記録方法、課題の登録方法を説明します。キックオフ中に、テスター全員に一度サインインしてもらいましょう。ユーザーやパスワードの問題の多くは、テスト日ではなくここで見つかります。

テスト日は 1 日か、1 週間か

• 1 日のテスト日を 1 つの部屋または 1 つの通話で行えば、集中でき、すぐに答えが得られます。スコープが小さい場合や、長時間テスターを確保しにくい場合に向いています。
• 数時間単位のブロックで1 週間に分散すれば、ブロックの間に修正と再テストの余裕が生まれます。多くのプロセスがある本番稼働に向いています。

どちらの場合も、毎日トリアージの時間を決めておきます。

UAT の最中

課題の登録

良い課題は、会議なしで修正できます。テスターには次の情報を求めましょう。

• ステップ、期待していたこと、実際に起きたこと。
• ページのスクリーンショット。
• レコードへのリンク。ブラウザーのアドレスバーにあり、開発者は問題が起きた商談やケースへ直接移動できます。
• テストに使ったユーザー。どのプロファイルと権限セットが使われたかがチームにわかります。

UAT Studio ではChrome と Edge 用のブラウザー拡張機能で、Salesforce の横のサイドパネルにテストが表示されます。ステップが不合格になると、スクリーンショット、レコードへのリンク、ページのエラーメッセージも一緒に記録されます。課題にはレコードがリンクとして表示され、Sandbox にも対応しています。

トリアージ

新しい課題は毎日、業務部門と Salesforce チームが一緒に確認します。それぞれに重大度と修正担当者を決め、次のいずれかを判断します。

• 修正：実際の問題で、このリリースで修正します。
• 却下：Salesforce は設計どおりに動作している、またはテストが誤っていた。
• 変更要求：不具合ではなく要望です。このリリースではなく、バックログに入れます。

再テスト

修正が Sandbox にデプロイされたら、課題を見つけたテスターがそのステップを再テストします。各再テストをどのビルドで行ったかを記録してください。大きな修正の後は、その周辺のプロセスも再テストします。

毎日のステータス

ステアリングコミッティには毎日、計画に対する進捗、重大度別の未解決の課題、妨げになっていることを簡潔に報告します。事実だけを伝えましょう。go/no-go 会議で驚きがないようにします。

UAT Studio ではトリアージは共有画面で、Fix、Reject、Change request を使って進めます。Ready for retest にすると再テスト担当者にメールが届きます。メールまたは Microsoft Teams で届く毎日の概要には、前日の結果と課題が表示されます。

サインオフと go/no-go

UAT は業務部門の判断で終わります。最後になって議論にならないよう、最初のテスト日の前に終了基準について合意しておきます。

• Critical の課題が未解決で残っていない。
• Must のテストケースがすべて合格している。
• 未解決の High の課題すべてに、業務部門が受け入れる回避策か修正予定日がある。
• スコープ内のすべてのテストケースに結果がある。

誰がサインオフするか

各プロセスのオーナーがサインオフします。たとえば、リードから入金なら営業部長、ケース管理ならカスタマーサービス部門の責任者です。オーナーは、承認、条件付き承認、却下のいずれかを選びます。条件はすべて、誰がいつまでに対応するかとともに記録します。そのうえで、ステアリングコミッティが本番稼働を判断します。

レポートに含めるもの

• スコープに含まれていたもの、テストしなかったもの。
• プロセスまたはチームごと、優先度ごとの結果。
• テストした Sandbox、リリース、ビルド。
• 重大度別の未解決の課題と、それぞれに対する判断。
• サインオフとその条件、そして最初の数週間の既知のリスク。

UAT Studio ではグループごとのサインオフ：Accepted、Accepted with conditions、Rejected。既定では、Critical の課題が未解決の間は誰も承認できません。最後の結果が入ると、go/no-go レポートが PDF またはスライドで用意されます。

Salesforce のリリースごとの回帰テストラウンド

本番稼働後もリリースは年 3 回続きます。そのたびに、ページ、フロー、権限が変わる可能性があります。UAT のテストケースは、業務部門が承認した内容を正確に表しているため、最良の回帰テストになります。

• 本番稼働後も、テストケースをステップ、テストデータ、期待結果とともに残しておきます。
• 次のリリースのリリースノートを読み、どの機能が自動的に有効になるかを確認します。
• UAT 用の Sandbox が Sandbox プレビューの対象になっていることを確認し、プレビュー期間中にラウンドを計画します。
• 業務部門の数名のテスターで Must のテストケースを再テストし、時間があれば Should も再テストします。
• UAT と同じように課題を登録し、リリースが本番環境に届く前に修正します。

UAT Studio ではプロジェクトの CRM として Salesforce を選びます。するとプロジェクトページに、今後の Salesforce リリースが、Sandbox プレビューの日付、本番の日付、リリースノートとともに表示されます。Start a regression round で、選んだテストケースをコピーします：Must and Should、Only Must、または All test cases in scope。

無料で使える

UAT の前、最中、後に準備すべきことについては、CRM 本番稼働のための UAT チェックリストをご覧ください。こちらも無料の Excel ファイルで提供しています。Salesforce の UAT で UAT Studio ができることについては、Salesforce UAT をご覧ください。

Salesforce、Sales Cloud、Service Cloud は Salesforce, Inc. の商標です。UAT Studio は Salesforce と提携しておらず、Salesforce の承認も受けていません。