自動化できたらうれしいテスト、してみたいテスト by T-DASH Advent Calendar 2023 3日目
Salesforceで テスト自動化について考えてみます。
私が主に使っているシステムについて
現在私はユーザ企業内でSalesforceの管理者として働いています。標準機能にない要件を実現するために、ApexとAuraコンポーネントを使ってカスタムコンポーネントを作成することもよくあります。また自動化処理ではApex バッチもよく作成します。
図1 ) こんな画面を作っています
また、SalesforceでのUIの開発では画面のレイアウトは独自のマークアップ言語、画面の制御はJava Script、データベース（オブジェクト）の操作はApexという独自の言語と３つのコードを書く必要があります。この部分も手動でのデバック、テストが面倒に思うところなんですよね。
実際のテストの内容について
Salesforceのテストで一番大変なのは、画面周りのテストです。実際にブラウザを使って確かめる必要があります。この部分は何か自動化のツールがあれば一番使ってみたいところです。またUIに関してはPCだけでなくスマートデバイスも気になるところです。カスタムコンポーネントではブラウザ前提の仕組みがあって、スマートデバイスでは機能しないこともあります。
Apexについては必ずTest用のApexクラスを作るので、このテストクラスを丁寧に作っておけば、コードの変更があってもテストは繰り返し的簡単に行うことができます。Apexについては単体テストはこのTest用のApexクラスで問題ないと思います。できればテストクラスを自動生成してくれるツールがあればものすごくうれしいですね。
システムテストは結局画面との連携で行う必要があるので、各クラス、メッソドの連携も自動化できればと思います。まぁ、別途専用のテスト用のクラスを作れば可能だとは思います。この場合は画面から実行される順番でテストを行っていくようなテストクラスを作りますが、画面の動きが変わると、使えなくなるのが難点です。やはり画面と連動してテストできるほうが便利だと思います。
図2 ) 画面の動きに合わせてテストを書いた例
調べてみるとSeleniumが使えるようですが、
Selenium などのツールを使用して構築された自動テストに何らかの適応を実装するには、単にテストを手動で実行するよりも多くの作業が必要になる場合があります。これは、Salesforce アプリケーション内で何かが変更されるたびに、テストの背後にあるコードを更新する必要があるためです。
とあるので、やはり上記のシステムテストでの懸念と同じ問題がありそうです。
Apexを使った REST APIについては Postmanでのテストの方法が理解できたので、Postmanを使って実施すれば問題ないと思います。
やはり一番試したい自動化は画面をテストすることですね。
以下の資料でも言及されているのですが、Salesforceは年３回のバージョンアップが実施されています。どんどん機能が追加されることはうれしいのですが、カスタム画面にも思わぬ影響を及ぼすことは案外あるように思います。私の場合は見た目にもこだわっているので、デザインはできるだけSalesforceの標準に合わせています。そのためLightning Design Systemを使っています。ただ、バージョンアップの時に使っている設定が非推奨になってなくなっていることもあるので、見た目が変わったり、表示されなかったりもたまにあります。この辺りも本当はテストをしないといけないのですが、なかなかできていません。テストの自動化で対応できればうれしいところです。
なぜ Salesforce でテストするのか?
Salesforce を使用している組織ではアプリケーションがカスタマイズされている可能性が高く、その品質をテストする必要があります。テストの目的は、自信を持って製品を提供できるように、製品に関する情報を学んで明らかにすることであると指摘しています。Salesforce でのテストが必要である理由は次のとおりです。
- テストにより、コードが機能的であることが保証される。
- テストにより、問題を早い段階で検出できる。
- テストにより、カスタムアプリケーションが組織に適切にリリースされることを確認できる。
Salesforceのテストの自動化の整理
なるべく最新の記事でよくまとめられているものを見つけることができました。残念ながら英語だったので、理解できるように自動翻訳してみます。
- メインの原文：The Ultimate Guide to Salesforce Test Automation in 2023
- (*1)と言う形で追加した原文:Salesforce test automation: A complete overview
Salesforce CRM をテストする場合、2 つのオプションがあります。1 つ目は手動テストです。問題を根本的に解決するためにテスト チームが従来の方法を実装する必要があるため、これには時間、労力、コストがかかる可能性があります。
2 番目のオプションは、Salesforce 自動テストです。これは、Salesforce テスト ツール (以下の例を参照) を使用して、システムのあらゆるレベル (ユニット、システム、UAT、本番、回帰) をテストします。
単体テスト
テストプロセスのこの部分は、Salesforce で使用される特定の言語である APEX を専門とする開発者によって実行されます。コードへの小さな追加はバックグラウンドで実行され、正しく動作しているかどうかが自動的にチェックされます。
システムテスト
テストプロセスのこの部分は、Salesforce 固有の専門家によって実行され、ビジネスの正確な出力と用途に関連します。システムテストでは、Salesforce CRM の自動化側の問題が明らかになります。
ユーザー受入テスト(UAT テスト)
Salesforce 自動テスト ツールの 1 つである UAT テストは、Salesforce アプリケーションを使用するユーザーによって実施される必要があります。テストでは実際のイベントや企業内での日常的な使用状況を模倣するため、アプリケーションがニーズに適合しているかどうかを確認できます。
実稼働環境でのテスト
システム テストの一部として実行されたのと同じテストが実稼働環境でも繰り返され、コードと構成がテスト環境またはサンドボックス環境から実際のアプリケーションに適切に変換されたかどうかが確認されます。この手順の後に UAT テストを繰り返すことをお勧めします。
回帰テスト
このタイプのテストは、新しい Salesforce 更新がリリースされてインストールされた後、またはバグが検出されて修正された後に開始されます。これにより、変更が加えられた後も、以前のすべての使用とプロセスが引き続き正常かつ効果的に実行されることが保証されます。
負荷テスト
Salesforce 環境はトラフィックやプロセスの流入にどのように対処しますか? 負荷テストは、処理要求が増大した場合の Salesforce 組織のパフォーマンスを測定し、組織の「限界点」を見つけます。この点を理解すると、環境を予期せずクラッシュさせる可能性のあるトラフィックやプロセスの流入に備えて計画を立てることができます。(*1)
ご覧のとおり、これらのさまざまなレベルをテストするには、さまざまなプログラミング言語とスキル セットが必要です。これらすべてに対応する自動テスト システムを構築するのは困難であるため、当初は手動テストが優先されました。
Salesforce のテスト自動化は以前から存在していました。しかし、上で概説した理由により、企業はこれを採用することが困難であると感じています。手動テストでは、少なくとも、情報に基づいた意思決定を行い、特定のシステムのニーズに合わせて行動を調整できる人間を相手にすることになります。Selenium などのツールを使用して構築された自動テストに何らかの適応を実装するには、単にテストを手動で実行するよりも多くの作業が必要になる場合があります。これは、Salesforce アプリケーション内で何かが変更されるたびに、テストの背後にあるコードを更新する必要があるためです。
しかし、最近では、はるかにユーザーフレンドリーで直観的なツールが登場し、継続的なコーディングを必要とせず、テスターの作業時間を大幅に短縮できるため、テスト自動化は Salesforce CRM にとって実行可能な推奨オプションとなっています。
Salesforce テスト自動化の課題(*1)
Salesforce は、常に機能が強化されている複雑なシステムです。ただし、これらの機能強化により複雑さが増す可能性もあります。つまり、自動テストの途中でいくつかの速度上昇が発生する可能性があります。
テスト スクリプトには時間と労力が必要です
オリジナルのスクリプトを正しく理解するには、多くの時間と忍耐が必要となるため、系統的に実行してスクリプトが正確であることを確認することで、長期的には時間を大幅に節約できます。残念ながら、Salesforce がテストに直接影響する更新をリリースすると、苦労した作業が台無しになる可能性があります。
動的要素
各環境は固有であり、フィールド、オブジェクト、統合が異なります。これは動的要素には触れていないため、テスト スクリプトの実行時に変化または変化する可能性があります。これにより、テストで要素を特定し、テストに失敗することが困難になります。
頻繁な更新
Salesforce はアップグレードや新機能を継続的に展開しているため、テストが予想以上に頻繁に中断される可能性があります。テストを適切に機能させるには、テスト スクリプトの修復と改善を常に行うための、実証済みの方法に時間を投資する価値があります。さらに問題を複雑にしているのは、Salesforce テストの多くは組織のスナップショットを使用して実行されるため、結果が表示された時点ではデータがすでに古くなっている可能性があります。
チームの経験不足
Salesforce の「コードではなくクリック」スタイルの開発スタイルは、管理者も開発者も同様に利用できますが、これは必ずしもテスト側に移されるわけではありません。スクリプトは、一定レベルのトレーニングを受けたチーム メンバーが作成する必要があります。テスト自動化ツールは数多くありますが、適切なツールを選択して適切に実装するには、テストのベスト プラクティスに関するある程度の知識が必要です。
手動テストはまだ必要ですか?(*1)
自動テストの利点を読んだ後、この質問に対する答えは「ノー」だと思うかもしれません。しかし、手動テストを行う時間と場所はまだあります。手動テストは大規模には機能しませんが、人間の介入の必要性を完全に無視する必要があるという意味ではありません。たとえば、ユーザー受け入れテスト (UAT) は、アプリケーションを使用するときにユーザーがどのように感じるかに依存します。これは、マシンではテストできません。このタイプのテストは通常、変更が期待どおりに機能することを確認するために、サンドボックスまたは UAT 環境で実行されます。
UAT テストは主観的であり、人間のやり取りや感情に依存するため、これらのテストは人間が実行する必要があります。ユーザーは UI 内を移動するときにどのように感じますか? 特定のフィールドやボタンの配置や機能に満足していますか、それともイライラしていますか? これらの質問は、人間のテスターが行うと常に良い結果が得られます。
同様に、ある程度の自然な創造性と好奇心が必要とされるため、QA テストを自動化することはほぼ不可能です。自動化では考えたり、提案したり、協力したりすることができないため、このレベルのスキルと認知能力を必要とするものは単純に自動化できません。このスタイルのテストでは、他のテストでは簡単に発見できない欠陥を見つけるのは個人に依存します。QA テストは、未完成または効果のない更新や変更のリリースに対するセーフティ ネットとして機能します。
テスト自動化の一般的な使用例(*1)
何がテスト自動化の候補となるかを判断するのは困難ですが、すべてのテスト ケースを自動化する必要はありません。代わりに、あなたとあなたのチームに最大の利益をもたらすものだけに焦点を当ててください。どれがどれであるかを判断するには、テストを行う必要がある頻度、テストの複雑さ、チーム全体にとって重要かどうかなどを考慮する必要があります。
自動テストの最適な使用例は、一貫性があり反復可能なプロセスです。つまり、複数のビルドにわたって一貫して使用できるプロセスです。これにより、人的ミスのリスクがなくなり、時間を節約できます。
目的を持って手動テストを使用する
手動テストがより適切な場合を見てみましょう。
-
限定的なテスト
テストの自動化は、長期的には時間とリソースを節約できますが、1 回か 2 回のみ実行することを目的としたテスト スクリプトの場合は同じ目的を果たしません。自動テストの設定には手間がかかるため、一定期間にわたって繰り返されるテストのためにその作業を保存しておくことをお勧めします。テストの実行時間が長くなり、頻度が高くなるほど、自動化の候補として適しています。期間が短い場合は、手動テストに固執してください。 -
探索的テスト
すべてのテストが自動化できるわけではありません。探索的テストは人間の思考を必要とするため、その 1 つです。探索的テストでは、エンジニアは知識、創造性、分析を活用して、製品内の未知の部分を明らかにします。これらの不明な点がいくつか見つかったら、チームは自動化で監視する必要があるかどうかを決定できます。 -
ユーザビリティ テスト
最終的な目標はエンド ユーザーにとっての品質であり、エンド ユーザーにとって、それは製品が機能し、使いやすいことを意味します。ユーザビリティ テストでは、製品とその機能が対象ユーザーにとって使いやすいかどうかを確認します。このフィードバックを得るために、代表的なユーザーのグループが、ツールでは回答できない質問、つまりナビゲーションはどの程度直感的ですか? という質問に答えます。美的に美しく見えますか？壊れたリンクはありますか? 等々。
ビジネスに Salesforce テスト自動化が必要な 6 つの理由
Salesforce システムに自動テストサービスを実装することには多くの利点があり、手動によるトラブルシューティングや修正に費やす時間を減らし、よりスムーズで効果的な使用が可能になります。
より広範なテスト
自動化された Salesforce テストを使用すると、可能性の高いものと可能性の低いものを含め、あらゆる数の事象やシナリオをカバーする数百のテスト ケースを実行できます。自動テストを使用している企業は、新しいテストに対応するテクノロジーと範囲をすでに備えているため、新しいリリースやアップデートに適応する能力もはるかに高くなります。
より効率的なテスト
従業員は企業にとって最も高価なリソースです。時間のかかる手動テストの必要性がなくなると、プロセスが高速化されるだけでなく、人的エラーのリスクも軽減されるため、テストをやり直す必要がほとんどなくなり、常に信頼できるデータがフィードバックされます。人間の行動に関する研究では、反復的で退屈な作業を頻繁に行うほど、間違いを犯す可能性が高くなることが示されています。そのため、テスターが 1 つのプロジェクトに長く取り組むほど、何かを見落としたり間違ったりする可能性が高くなり、結果としてテストがやり直されることになります。自動テストを使用すると、このリスク要因を完全に取り除くことができます。
繰り返しテストのスケジュールを設定する
各テストの基礎を設定したら、ボタンをクリックするだけでテストを無限に繰り返すことができるため、大規模なテスト プログラムの実行に必要な人員が削減されます。繰り返しテストのスケジュールを設定するのは簡単で、テスターは同じ繰り返しプロセスを一度に何時間も、場合によっては何日もかけて手動でたどる必要はありません。
自動レポート
テストが完了したら、Salesforce アプリケーションの成功と失敗の側面を評価するための詳細なレポートを作成する必要があります。これらのレポートを手動で作成するには時間がかかる場合があります。ただし、自動テストとは自動レポートを意味します。これらのレポートにより、再実行が必要なテストを特定し、エラーが発生している可能性のある場所を特定することが簡単になります。テストを記録して再生用に保存できるため、テスターはさらに貴重な洞察を得ることができます。
テスターを解放する
自動システムが日常の日常的なテストを実行することで、専門のテスターは Salesforce CRM をさらに改善するためのより大きなプロジェクトの設計に時間を費やすことができます。既存のテスト イニシアチブの実行と監督に時間を費やすのではなく、新しい問題解決のアイデアを開発することに集中できます。
問題を迅速に特定する
すべてのテスト システムの主な目的は、Salesforce CRM の効率的な実行を妨げている問題を根絶し、修正や改善できるようにすることです。テストでは、構成の問題やコードの破損行を特定し、それらを簡潔なレポートとして渡すことができるため、テスターは問題が深刻になる前に問題を迅速に解決できます。最終的には、これが自動テストの目的です。
何をテストできますか?
Salesforce システムを効率的に使用するには、ソフトウェアの統合からクライアントの連絡先詳細の収集に至るまで、その実行プロセスのあらゆる側面をテストする必要があります。自動テストでチェックすることをお勧めするプロセスには次のものがあります。
- 顧客情報を正しく収集する
- Web フォームにデータが正しく入力されている
- レコードは重複していません
- クライアントのステータスは、対話中および/または販売後に変更される可能性があります
- 連絡先を顧客または見込み客としてマークできる
- 許可されたユーザーのみが特定のレコードを表示できます
- フィールドはルールセットに応答しています (たとえば、価格をゼロにすることはできません)
- 自動メールが送信されています
- 請求書は正しく作成されています
- サードパーティのアドオンは機能します
- ワークフローはモバイル デバイスや他のブラウザーで期待どおりに実行されます
企業が利用できるツールは無数にありますが、その中には他のツールと比べて際立ったツールもあります。以下にリストされている Salesforce 自動化ツールのいずれかを使用することをお勧めします。MagicFuse は、適切な Salesforce テスト自動化ツールの選択と自動化の設定を支援します。
Provar - Provar は、Salesforce とその広範なエコシステムで最も人気のあるテスト自動化ソリューションの 1 つです。これは、Salesforce 向けに特別に設計された唯一のツールであり、直感的なアプローチを採用しているため、初日からテスト チームがテストを実施できます。Provar は、顧客サポートとコンサルティングで賞を受賞しており、活発なコミュニティを提供し、便利で使いやすいインターフェイスを備えています。
OpKey - OpKey は AI を活用した継続的テスト プラットフォームであり、Salesforce 向けの最初の予測テスト プラットフォームです。AI は、Salesforce システムにどのようなテストとアップグレードが必要になるかを予測し、常に先手を打つのに役立ちます。ユーザーは、事前に構築されたテスト自動化のライブラリ、AI ベースの影響分析、あらゆる障害を克服する直感的なテスト ビルダーの恩恵を受けることができます。OpKey が多くの競合他社と異なる点は、ドラッグ アンド ドロップ プロセスを記録することで機能するモデルベースのテスト アプローチです。
Mabl - Mabl の主な目的は、テスターであるかどうかに関係なく、企業の IT チームの誰もがテスト プロセスにアクセスできるようにすることです。Mabl は、Salesforce の使用状況が頻繁に変化することを理解しているため、テスト プラットフォームはこれを反映する必要があります。Mabl は、テストする必要があるプロセスを記録することで機能するユーザー インターフェイスも提供します。
Tricentis - Tricentis によるエンドツーエンドのテストにより、何かが更新されるたびに CRM が統合アプリと連携してスムーズに動作し続けることが保証されます。テストは優先順位に合わせて調整できるため、最も重要なものが常に最初に処理され、冗長になったテストは自動的に削除されます。
Copado - この自動化ツールは、テスト用の完全にスケーラブルなプラットフォームと予測 AI ベースを備え、ビジネス内のイノベーションを促進することを目的としており、開発に集中できます。Copado は、エンドツーエンドのテストを実行しながら、Salesforce の仕組みを改善するのに役立つ実用的なデータを提供します。
Cigniti - このテスト ツールは、CRM と他のアプリやパーソナライズされた要素との統合をチェックすることに特化しています。Cigniti はサービスですが、パッケージ化されたガイドラインとテンプレートも提供しており、企業が初期設定にあまり手間をかけずにテスト システムを迅速に開始できるようにします。
ACCELQ - AI を活用したコードレス テスト自動化プラットフォームであるこのツールは、テスターによるコーディングを必要とせず、継続的にテストを実行でき、 Salesforce AppExchangeで利用できます。ACCELQ は、Fortune 500 企業によって世界中で採用されており、クラウド ソリューション、Web サービス、バックエンド テストなど、Salesforce エコシステム内のすべてを自動化できます。
Salesforce で自動テストを実行できますか?
テスト自動化 Salesforce は、アプリケーションを監視し、Salesforce 内および Salesforce と他のシステムおよびアプリケーションの間でプロセスが意図したとおりに一貫して実行されていることを検証するために使用されます。たとえば、企業は、ユーザーが製品を購入できる顧客向け Web サイトを持っているとします。
Salesforce の自動化をテストするのは難しいですか?
要素 ID を非表示にする: 通常、UI オートメーション ツールでは、アプリケーション内の視覚要素を識別するために要素情報が必要です。Salesforce は開発目的でこれらを非表示にするため、テストの自動化が困難になります。
無償ツール Selenium , WebDriver API
Salesforceの開発者フォーラムでの回答
テストは高品質のソフトウェアをリリースする上で重要な部分です。自動ソフトウェア テストでは、これらの日常的で単調なケースを実行できるため、テスト リソースが解放され、アプリケーション内のより興味深いケースに集中できます。適切に構築された自動テスト ピラミッドの一部として、ある程度のレベルの UI ベースの自動テストが必要になります。Web アプリケーションの場合、これはブラウザーを自動化することを意味します。
ブラウザのテストを自動化するために使用できるツールは多数あります。salesforce.com では、オープンソースの Selenium プロジェクトを使用して、Salesforce アプリケーションの機能に対して 40,000 を超えるテスト ケースを実行しています。これらのテストは、継続的統合ビルド インフラストラクチャの一部として実行されます。Selenium のおかげで、実際の自動化コードを変更することなく、さまざまなブラウザ上でテストを実行できます。また、Selenium ライブラリはオープンソースであるため、 Selenium コミュニティ全体に利益をもたらすために、問題を見つけ次第修正し、上流のプロジェクトに提出し直すことができます。
Selenium は、2004 年に ThoughtWorks の Jason Huggins らによって開始されて以来存在しています。Selenium を使用すると、Internet Explorer、Firefox、Chrome、Safari、Opera など、さまざまなブラウザを使用して同じテストを実行できます。また、Java、Ruby、Python、.NET 言語など、さまざまなクライアント言語でのテストの作成もサポートされています。
2009 年に Selenium プロジェクトは WebDriver プロジェクトと統合され、2010 年に Selenium WebDriver API を備えた Selenium 2.0 がリリースされました。その後のプロジェクトでは、この API をベースとして、モバイル Safari、Android デバイス上の Chrome、さらにはモバイル プラットフォーム上のネイティブ アプリケーション用のテスト ライブラリを作成しました。この API の優れた点の 1 つは、Salesforce 内のチームが単一のテストを使用して、ほとんどのデスクトップ ブラウザと現在の多くのモバイル ブラウザでアプリケーションを自動化できることです。
WebDriver API のもう 1 つの優れた点は、ブラウザ テストの推奨候補として含めるために World Wide Web Consortium (W3C) に提出されていることです。このプロジェクトがそのプロセスに組み込まれて以来、Web ブラウザー ベンダーが独自の WebDriver API 実装を提供し始めています。Opera と Chrome はどちらも WebDriver の実装を提供します。Mozilla の実装は、デスクトップ Firefox と新しいモバイル Firefox OS の両方で動作し、間もなく広く利用可能になる予定です。Salesforce にとって、これは、ブラウザ内テストのベースとなるツールが、それらのブラウザを最もよく知っている人々、つまりブラウザ ベンダーによって構築されているため、可能な限り安定していて信頼できることを意味します。
Selenium コミュニティは活気があり活発で、世界中に何万人ものユーザーがいます。社内で Selenium が広く使用されているため、セールスフォース・ドットコムは、2013 年 6 月 10 ～ 12 日にボストンで開催される第 3 回年次 Selenium カンファレンスのスポンサーであることを誇りに思います。スポンサーであることに加えて、セールスフォース・ドットコムの従業員も数名います。このカンファレンスで発表するのは誰ですか。David Louvton と Amol Gupta が「Selenium のスケーリング: Salesforce の Selenium インフラストラクチャ」と題した講演を行います。そこでは、継続的なプロビジョニングの方法を使用して、さまざまなプラットフォーム上で大規模なテスト ケースのライブラリをどのように実行できるかについて説明します。 Selenium テストを実行している仮想マシンのインスタンスを破棄します。Luke Inman-Semerau 氏の講演は「iOS MobileSafari.app の駆動」というタイトルで、WebDriver API を使用して iOS モバイル Safari アプリケーションをドライバし、Web ページのテストを実行する方法を示します。最後に、「Internet Explorer ドライバーの再考: 急速化」という気まぐれなタイトルの講演を行います。私の講演では、過去 1 年間に Internet Explorer 用の Selenium ドライバーに加えられた改善について説明します。
Web サイトのテストに投資している場合は、ブラウザー駆動の UI ベースのテストのソリューションとして Selenium を検討する必要があります。Quick Test Professional (最新名 UFT) は、ライセンス供与されたツールでSalesforceアプリケーション
を自動化するのに最適なツールです。Selenium 以外のオープンソースを探す場合は 、WATIR を使用した Ruby と Eclipse を使用した JUnit が、私が推奨できる最良のツールの一部です。詳細については、以下のリンクからご確認ください。
Salesforce特有の課題？
課題 1: 複雑な DOM 構造
他のアプリケーションに比べて、Salesforce のドキュメントオブジェクトモデル (DOM) 構造は複雑です。DOM では、Web サイト上のすべてのオブジェクトはツリーと呼ばれる型のデータ構造に整理されます。このツリーでは、階層内のすべてのオブジェクトが別のオブジェクトの下に配置されます。このような構造になっているため、Web 要素の検査は単純なプロセスではありません。
Salesforce Platform の大きな強みの 1 つは、コードではなくクリックでカスタマイズを作成できることです。宣言型開発の利点として、Web ページの構築にメタデータを使用することが挙げられます。コードを記述する必要はありません。たとえば、Web ページの左側にある要素を右側に移動させることができるため、コードの変更を心配せずにすみます。Salesforce に要素を配置する場所を指示するだけで、Salesforce でメタデータからページが表示される際に、Web ページのコードと DOM が自動的に再構築されます。
宣言型開発は、Salesforce のカスタマイズが容易になる一方で、DOM に依存する一部の自動テストツールにとっては課題となる可能性もあります。そのため、Salesforce から直接取得されるメタデータを使用する自動化プラットフォームを見つけましょう。これにより、テストが DOM 構造に依存しなくなります。
課題 2: 内部フレームワークの変更
Classic から Lightning への移行に伴い、内部フレームワークも移行しました。たとえば、Aura から Lightning Web コンポーネント (LWC) への移行です。この移行をまだ行っていない場合、または切り替えを見込んでいる場合、この変更によってロケーターが破損する恐れがあります。つまり、テストスクリプトを再作成する必要があります。
このような場合も、Salesforce メタデータを使用するような自動テストプラットフォームを導入していれば、Classic で使用していたテストスクリプトは Lightning でも問題なく動作します。フレームワークの変更によってスクリプトを書き直す必要はありません。
課題 3: Shadow DOM の背後にあるオブジェクト
一部の Salesforce アプリケーションでは、DOM 構造が Shadow DOM に変更されています。Shadow DOM では、通常の DOM ツリーの要素に非表示データを添付することが許可されます。これは、コーディングされた自動化フレームワークを使用している場合、以前に作成したスクリプトがすべて破損することを意味します。
この問題は、Salesforce メタデータを使用するテストソリューションを実装するもう 1 つの理由となっています。過去に作成したスクリプトも意図したとおりに動作するようになるため、スクリプトが Shadow DOM 構造で作成されたか、通常の DOM 構造で作成されたかを気にする必要はありません。古いテストスクリプトを直接実行することも、新しいスクリプトを問題なく作成することもできます。
課題 4: 毎年 3 回のリリース
Salesforce は年に 3 回、メジャーリリースを行っています。最善のシナリオであっても、このリリースがアプリケーションの機能に影響を与える可能性があるため、アプリケーションの再テストが必要になります。自動テストツールは、実行したい数多くの回帰テストや機能テストを実行するのに役立ちます。
テストソリューションが Salesforce のリリースにも対応していれば、この課題は自動的に克服されます。