TELUISteluis tech

Salesforceのテスト自動化はなぜ「無理ゲー」と言われるのか？QAエンジニアが直面する5つの壁と現実解

Salesforce QA テスト自動化

「Salesforceの画面テスト、SeleniumやPlaywrightでパパッと自動化しといて！」

プロジェクトでこんな無茶振りをされたこと、あるいは自分から意気揚々と挑戦して数週間後に**「二度とやりたくない……」**と頭を抱えた経験はないでしょうか。

WebアプリケーションのE2E（End-to-End）テスト自動化は昨今の開発において一般的になってきましたが、「Salesforce（特にLightning Experience）」を対象にしたテスト自動化は、Web開発の中でもトップクラスに難易度が高い領域です。

今回は、QAエンジニアや導入支援・開発エンジニアが現場で直面する「Salesforceテスト自動化が難しすぎる理由」と、挫折しないための現実的なアプローチについて解説します。

Salesforceテスト自動化を阻む「5つの壁」

1. Shadow DOM（LWC）と「動的セレクタ」の壁

SalesforceのLightning Experienceは、**LWC（Lightning Web Components）**というWeb Components標準技術をベースに構築されています。

Web ComponentsにはスタイルやDOMのカプセル化を目的としたShadow DOMという仕組みが存在します。これがテスト自動化ツールにとっては非常に厄介です。通常のDOMツリーとは隔離された境界（Shadow Root）を持つため、従来のSeleniumなどで使われていた標準的なXPathやCSSセレクタでは要素を簡単に取得できません。

さらに、Salesforceが描画するHTML要素のidやclassの多くは動的にハッシュや乱数が付与されます。

<!-- 属性やIDが実行時やリリースごとに変わる例 -->
<button id="123:0" class="slds-button slds-button_brand lightningInput-input_hash">
  保存
</button>

「要素が見つからない」「IDが次回実行時に変わっている」という問題が日常茶飯事で発生し、セレクタを維持するだけで膨大な工数が溶けていきます。

2. 年3回（Spring / Summer / Winter）のバージョンアップ

Salesforce最大の特徴であり強みでもある「年に3回のメジャーバージョンアップ」。しかし、テスト自動化の文脈では**「定期的にテストが爆発する時限爆弾」**になります。

Salesforceのバージョンアップでは、画面の見た目がほぼ変わっていなくても、内部のDOM構造、コンポーネントの入れ子構造、クラス名などがサイレントに変更されることが多々あります。

苦労して安定させたはずの自動テストが、メジャーリリース直後に**全滅（一斉にFail）**し、メンテナンスに追われて開発スピードが落ちるという本末転倒な事態が頻発します。

3. iframeと非同期レンダリングによる「Flaky（不安定）テスト」

Salesforceの画面は、1つのページの中に多数のコンポーネントが非同期に読み込まれます。

  • 遅延読み込み（Lazy Loading）
  • コンポーネントごとのAPIコール
  • VisualforceやAppExchangeによる多重iframe
  • 仮想スクロール（画面外の要素がDOMから消える）

これらが組み合わさる結果、「テスト実行のタイミングによってボタンがまだ押せない」「モーダルが開く前にクリックして空振りする」といったFlaky（成功したり失敗したりする）テストが量産されます。

明示的な待機（Wait処理）をスクリプト中に散りばめることになりますが、待機時間が長くなりテスト実行時間が肥大化する悪循環に陥りがちです。

4. 複雑怪奇な権限・プロファイルとテストデータの壁

Salesforceの強みは柔軟なアクセス制御ですが、テスト自動化にとっては最大の鬼門です。

  • プロファイル（Profile）
  • 権限セット（Permission Set）
  • 共有ルール（Sharing Rules）
  • レコードタイプ（Record Type）

これらによって「同じ画面でも、ログインユーザーによって表示される項目やボタンが全く異なる」という状態が普通に起こります。

また、テストデータの準備・後片付け（クリーンアップ）も容易ではありません。画面から手作業でデータを作る自動テストは遅すぎますし、API経由で作成しようにも複雑なバリデーションルールやトリガー、フローが絡み合い、テストデータの依存関係を解消するだけで専門知識が必要になります。

5. 「標準機能」と「独自開発」のハイブリッド構造

Salesforceプロジェクトでは、標準のオブジェクト・画面レイアウトに加えて、独自のLWCや画面フロー、カスタムボタンなどが混在します。

「ここは標準コンポーネントだから仕様が変わる可能性がある」「ここは自社開発だからセレクタを制御できる」といったグラデーションが存在するため、一貫したテスト自動化ポリシーを策定するのが難しく、ルールが形骸化しやすいのです。

現場で爆死しないための「現実的な処方箋」

では、Salesforceプロジェクトではテスト自動化を諦めるべきなのでしょうか？
結論から言うと、「フルスクラッチのSeleniumで画面を端から端まで自動化しようとするアプローチ」は諦めた方が賢明です。

現場で成功させるための現実解は以下の4点です。

① テストピラミッドを意識する（E2Eに頼りすぎない）

テスト自動化の基本ですが、Salesforceでは特に重要です。

  • Apexテスト（単体テスト）: ビジネスロジック、トリガー、バッチはApexで徹底的に自動テストを書く（Salesforceのデプロイ要件でもあります）。
  • APIテスト: REST API経由でフローやインテグレーションの挙動を検証する。
  • UI（E2E）テスト: 最も壊れやすいので、「ログイン〜主要な成約フロー（Critical Path）」のみに限定する。

画面のあらゆるバリデーションエラーや細かいレイアウト崩れまでE2Eで担保しようとしない勇気が必要です。

② Salesforce公式の「UTAM」を検討する

Salesforce公式が提供している**UTAM（UI Test Automation Model）**というフレームワークがあります。 これはPage Objectパターンをベースに、Salesforceの標準コンポーネントのセレクタ定義（JSON形式のページオブジェクト）を公式が管理・提供してくれる仕組みです。

バージョンアップによるセレクタ変更を公式のページオブジェクト更新で吸収できるメリットがありますが、導入コストや学習コストが比較的高いため、プロジェクト規模や開発チームのスキルセットと相談して採用を決める必要があります。

③ Salesforce対応を謳う商用ノーコードツールの検討

もし予算が許すのであれば、PlaywrightやSeleniumを自前で組むのではなく、SalesforceのShadow DOMや動的要素に標準対応しているテスト自動化ツール（例: Provar、mabl、Autify、Tricentisなど）を検討するのも有力な選択肢です。

特にProvarなどはSalesforceメタデータを直接読み取ってテストを構築できるため、DOMの変化に強いテスト資産を作ることができます。

④ テスト自動化の「目的」をチームで合意しておく

「テストを100%自動化してQA工数をゼロにする」という非現実的なゴールを設定すると、ほぼ確実に破綻します。

  • 「年3回のSalesforceリリース前に行う、主要業務フローのリグレッションテスト（回帰テスト）を数時間で終わらせる」
  • 「日々のデプロイで致命的なデグレが起きていないことを夜間にスモークテストする」

このように、**「費用対効果が高いスコープに絞る」**ことこそが、Salesforceテスト自動化プロジェクトを成功に導く最大の秘訣です。

まとめ

Salesforceのテスト自動化は、Webの一般知識だけで突っ込むと高確率で挫折する地雷原です。

しかし、その難しさの本質（LWC/Shadow DOM、動的要素、年3回のリリースサイクル）を正しく理解し、テストピラミッドに沿って適切なレイヤーでテストを設計すれば、保守可能で価値の高い自動化を実現できます。

次回以降は、具体的なSalesforceテスト自動化の設計パターンやツールの比較についても掘り下げていきたいと思います。