Salesforceの変更を受け入れるときのテストの進め方

受け入れテストの位置づけ

ユーザー受け入れテスト（UAT）は、利用者が Sandbox などのテスト環境で行うテストです。変更が意図どおりに動くか、最初に頼んだ機能が実際に入っているかを確かめます。[1]

順番としては、作る側のテストが済んだ後に行う、本番に出す前の最後の段階です。結果は合格か不合格かで出し、本番に出すかどうかの判断につながります。[1][2]

公式のリリースのベストプラクティスでも、本番で直接作り込まず、専用の環境で変更してテストすることを勧めています。その中に、Partial Copy または Full Sandbox で関係者が変更を試す機会を設けることが挙がっています。[5]

テストの種類

• 種類 1単体テスト組織に加えたコードの、いちばん小さな単位を確かめます。コードを書いた変更で要ります。2026年10月時点で、Apex を本番に出すには、コードの 75% 以上がテストされている必要があります。[2][10]
• 種類 2結合テスト組織の外のシステムや、別の Salesforce 組織とやり取りする部分を確かめます。[2]
• 種類 3機能テスト技術的な要件どおりに機能が動くかを確かめます。小さな案件では受け入れテストとまとめることもあります。[2]
• 種類 4受け入れテスト利用者が、出来上がった機能を受け入れるか断るかを決めます。[2]
• 種類 5回帰テスト変更で、今ある機能が壊れていないかを確かめます。Trailhead の例では、ステージング用の Sandbox で行います。[2][3]
• 種類 6性能テスト大量のレコードや処理を扱うときの応答を確かめます。これに対応する Sandbox は Full Sandbox だけです。[2][4]

テスト環境（Sandbox）

Sandbox の種類ごとに、向く使い方が決まっています。Developer Sandbox は本番の設定だけを写した、開発とテスト用の環境です。Partial Copy Sandbox は、受け入れテストや結合テストなどに使う種類で、テンプレートで選んだ本番データの一部が入ります。[4][8]

Full Sandbox は本番の複製で、性能テスト、負荷テスト、ステージングに対応するのはこの種類だけです。Trailhead の例では、受け入れテストを通った変更を Full Sandbox に載せ、回帰テストを行ってから本番へ進みます。[4][3]

性能テストを行うときは、Salesforce のサポートに前もって知らせるよう、Trailhead に書かれています。止められないようにするためです。[2]

同じテストをやり直すときは、Sandbox を更新したり設定を戻したりして、前回の結果が残らないようにします。[2]

テストケースと受け入れ条件

受け入れ条件は、要件ごとに付ける、合格か不合格かがはっきり決まる文の集まりです。要件ごとに 1 つ以上置き、1 つずつ単独で試せて、正しいか正しくないかで答えられる形にします。[11]

書くのは「何ができるか」で、「どのボタンを押すか」ではありません。条件は意図を表し、作り方は表さないようにします。[11]

テストケースは、この受け入れ条件をもとに、確かめる場面と操作の手順を書き出したものです。正しい操作だけでなく、誤った入力をしたときの動きも確かめます。[1][12]

全部を同じ重さで試す時間はないこともあります。Trailhead は、商談やケースの作成のように業務に欠かせないものと、ほとんどの人が使うものから優先する考え方を示しています。[2]

あわせて、どこまで試せば終わりとするか（終了条件）も、始める前に決めておきます。[12]

テスト用のデータとユーザー

Developer Sandbox には本番のデータが写らないため、テスト用のデータを作ります。Partial Copy や Full Sandbox では、どのデータが入っているかを始める前に確かめます。[2][1]

Sandbox を作ると、ユーザー名の末尾に Sandbox 名が付きます。テストする人には、このユーザー名でログインしてもらいます。[6]

試す人は、業務を知っている利用者から選びます。Trailhead の対談では、現実に合わないテスト手順と、業務に詳しくない試験者のまま承認し、本番で大きな抜けが見つかった例が語られています。主な利用者の役割ごとに、主要な機能を試すのが一つの方法です。[1]

画面の不具合は、端末やブラウザ、プロファイルによって出ることがあります。Trailhead は、よく使われる組み合わせで試すよう勧めています。[2]

メールにも注意が要ります。Sandbox はユーザーのメールアドレスを変えますが、取引先責任者のメールアドレスは変えません。送信を試すときは、試験者のアドレスに置き換えます。2026年10月時点で、新しい Sandbox の既定の送信設定は「システムメールのみ」です。[6][7]

結果の記録と本番に出す判断

始める前に、不具合や質問を誰にどう伝えるかの流れを決めておきます。結果はテストケースごとに合格か不合格かで残します。[1]

見つかった不具合は、重さで順番を付けて対応します。Salesforce 側の既知の問題（Known Issues）に載っていないかも確かめます。直す時間は、計画の段階で見込んでおきます。[12][2]

テストでエラーが出たら、直してからテストをやり直します。[3]

本番に出す判断は、テストの結果と、業務の関係者からの書面での承認（サインオフ）をそろえて行います。新しい問題が出たときに、出すか見送るかを決めることも、受け入れの段階の役目です。[1][13]

出す前には、検証（本番に反映させずにテストの結果だけを確かめる操作）を行います。変更セットのリリースはロールバックできないため、出す前に結果を確かめておきます。[3][9][10]

Trailhead の例では、本番での検証は問題に対応できる営業時間中に行い、反映は利用者の少ない時間に回しています。休日や大きな行事の直前のリリースは避けます。出した後は、本番で主な動きを軽く確かめます。[3][5]