2026 Salesforceメールログイン認証コードのテスト方法？QA受け入れ手順

Salesforceの公式説明では、メールログインの既定の体験はサンドボックスで2026年8月から、本番組織で2026年10月から段階的に導入されます。ログイン変更の説明どおり組織ごとに切り替わるため、Salesforceメールログイン認証コードのテストでは、メール入力、コード受信、アカウントや組織の選択、最終ログインを別々に確かめてください。メールが届いただけでは合格にできません。

対象読者：サンドボックスやテスト組織のログイン回帰を担当するQAエンジニア。
ログイン自動化を保守する開発者と、複数のテスト組織を管理する担当者にも向けています。

最終更新日：2026年11月2日。Salesforce公式のログイン変更、メールログイン、ログインURL関連資料を確認しています。個々の組織で実際に表示される画面は、その組織での実行記録として扱ってください。

実行前に組織とログイン入口を特定する

まず、確認対象がサンドボックスか本番組織かを記録します。次に、スクリプトが使う入口を、共通ログインページ、My Domain、Experience Cloud、SSOのどれかに分けます。入口が異なると、同じ画面や認証の流れになるとは限りません。

Salesforceのメールログインに関する説明は、すべてのログイン方式へ一律に当てはめるものではありません。メールアドレスでのログインに関する公式説明と、ログインURLの選択に関する案内を照らし合わせ、受け入れ対象の入口を先に決めます。モバイルアプリやSSOを検証する場合も、共通ログインページの結果をそのまま流用せず、対象方式の公式案内を確認してください。

実行記録には、対象組織、入口、アカウントの種類、メールアドレスを入力した後の画面を残します。組織単位で段階導入されるため、一度の表示だけから「すべての組織で切り替わった」とは判断できません。

最初のログインで現在の画面遷移を記録する

自動操作の前に、許可されたテストアカウントを使って手動で一度ログインします。メールアドレス入力後に何が表示されるか、認証方法の選択肢があるか、どこへ遷移するかを順番に記録してください。表示を事前に決めつけず、実際の対象組織で観察します。

初回の観察は、あくまでその組織、その入口、その時点での結果です。Salesforceの公式説明と画面の両方を確認し、片方だけで全組織の仕様を推測しないことが重要です。My DomainやExperience Cloud、第三者のSSOを経由する試験では、共通ログインページの挙動と混ぜず、別の試験条件として管理します。

認証コードの受信と画面での受理を分ける

メールアドレスに複数のアカウントが関連付いている場合、メールの認証コードを使って本人確認し、その後にアカウントを選択する流れが案内されています。複数のアカウントを使うログイン手順を参照し、該当するテストアカウントでコードを求められるか確認します。すべてのアカウントで必ず同じ画面が出るとは仮定しません。

受信確認では、テスト用メールアドレスと今回のログイン操作が対応していることを見ます。次に、受信したコードを画面へ入力し、受理されたか、エラーになったか、次の画面へ進んだかを別々に記録します。メール受信の成功は、コード入力の成功を意味しません。

メールが見当たらないときは、まず入力した宛先と受信箱を確認し、迷惑メール扱いやテスト環境側の受信制限も調べます。認証コードの有効時間や到着時間は、ここで確認できる共通仕様として決めつけず、公式の現行説明と実際の画面に基づいて扱ってください。

受信先の分離方法を検討するときは、テスト用メールアドレスの受信確認ポイントも参考にできます。ただし、利用するアドレスが対象組織の試験条件に合うかは、実際のログインで確認してください。

コード入力後に正しい組織を選ぶ

コードが受け付けられた後に、複数のアカウント、ユーザー名、組織などの選択肢が出る場合は、選択前と選択後の状態を記録します。テスト対象の組織に対応する候補を選んだかを確認し、ログイン後の組織名や対象ページなど、あらかじめ決めた判定項目で到達先を検証してください。

結果は「認証成功」「別の組織を選択」「コード入力後も認証画面に残る」のように分けると、失敗箇所を追いやすくなります。認証コードのメールだけでは、最終的なアクセス権や組織の正しさは証明されません。

Salesforceのメールログイン認証コードをQAで判定する

次の条件分岐で試験方式を選びます。

• 対象がメールログインで、メールアドレスに複数のアカウントが関連付いている場合は、コードの要求、受信、画面での受理、アカウント選択、到達先までを一連の試験として実施します。
• メールログインが対象でも、該当するアカウント選択条件がない場合は、実際に表示された認証手順を記録し、コード画面が必ず出るとは決めつけません。
• 目的が従来のユーザー名ログインの確認である場合は、ユーザー名ログイン用の入口を公式資料で確かめて別のテストケースにします。メールログイン画面の固定位置に依存した操作は避けます。
• SSO、Experience Cloud、モバイルアプリが対象の場合は、共通ログインページの試験結果を合格根拠にせず、その方式に対応する手順を別途確認します。

自動化では、メール入力、メール到着、コードの入力結果、アカウント選択、最終画面を独立した検査点にします。固定ボタン位置や一度だけ観察した文言を、長期間変わらないセレクターとして扱わないでください。モバイルアプリのログインは、Salesforce公式のモバイルログイン説明も確認し、Webの結果と区別します。

複数のテスト組織で同じメールアドレスを使う場合は、アカウントと受信先の対応関係も管理します。テストデータとアカウントを分ける考え方を参考に、実在の個人情報を含む受信先を回帰テストへ持ち込まない運用にすると、誤選択や不要な通知を調査しやすくなります。

自動回帰の合否を状態別に記録する

表の評価は、どちらが常に優れているかを示すものではありません。試験目的に合う経路を選び、別経路の合否まで一つの結果にまとめないための整理です。Salesforceテスト組織ログインの記録には、入口、アカウント種別、コード受信、コード受理、選択した組織、最終状態を残します。失敗時に、どの段階で止まったかを再現できることが合否判定の基準です。

よくある確認事項

Salesforceのテスト組織でメールログインを検収するときは何を残しますか？

入口の種類、対象組織、テストアカウント、メールアドレス入力後の画面、コードの受信と入力結果、組織選択、最終状態を分けて記録します。サンドボックスでの結果を、本番組織や別のログイン方式にそのまま当てはめないでください。

1つのメールアドレスに複数のアカウントがある場合はどう検証しますか？

コードの要求と受信を確認した後、入力したコードが画面で受理されるかを確かめます。続いて候補のアカウントや組織から対象を選び、ログイン後の状態がテスト対象と一致することまで確認します。

自動テストでユーザー名ログインを続けるにはどうしますか？

対象組織で利用するログイン入口を公式資料で確認し、ユーザー名ログインのケースをメールログインのケースから分けます。URLパラメーターを使う場合は、現行の公式案内に沿って設定し、画面上のボタン位置や文言を固定条件にしないでください。

認証コードが届けばログイン成功ですか？

いいえ。受信の確認後にコードが画面で受理されるか、必要なアカウントや組織を選べるか、最終的に対象組織へ到達したかを確認します。それぞれを別の状態として記録すれば、メール配送の問題とログイン経路の問題を切り分けられます。

テストアカウントの受信先には、管理されたテスト用アドレスを使う方法もあります。受信確認を切り分けたい場合は、登録不要ですぐ使えるMsgMaskを候補にできますが、対象組織で必要な受信や継続利用の条件に合うか、先に実際のテストで確かめてください。長期的なアカウント復旧や継続受信が必要な用途では、管理下にある業務用アドレスを選ぶのが安全です。

よくある質問