B2C Commerce 実装のテスト

学習の目的

この単元を完了すると、次のことができるようになります。

• B2C Commerce 実装プロジェクトのテストフェーズにおける顧客の責任を特定する。
  
• B2C Commerce 実装プロジェクトのテスト計画に含めるテストを特定する。
  

テストの準備

おめでとうございます。NTO サイトの立ち上げにまた一歩近づきました。この列車の旅の停車駅も、テスト、立ち上げ、立ち上げ後と、残すところ 3 つのみになりました。まず、サイトに厳格なテストを実施して、あらゆるバグを検出します。その準備をしましょう。

ディスカバリーフェーズで NTO のプロジェクトマネージャーに、リソースをテストチームに割り当てるよう助言しました。この時点で、テスターを呼び集めるようにプロジェクトマネージャーに伝えます。テストチームを招集してテストケースを作成するために要する時間を、顧客が過小に見積もることが少なくありません。十分な余裕をもって NTO に通知するようにします。

顧客へのトレーニング

テストの準備はその実施と同じくらい重要です。そして、Salesforce は顧客を準備させる方法を心得ています。ストアフロントの立ち上げ準備ブートキャンプ (LRBC) は、2 ～ 3 日間の実践的なセッションです。LRBC は SRA プロセスの一環です。このブートキャンプは、NTO がストアフロントのユーザー受け入れテスト (UAT)、サイト立ち上げ、サイトメンテナンスを準備するうえで役立ちます。LRBC を指導するのはファンクショナルアーキテクトの Mindy です。ブートキャンプのために優雅なラウンジカーを予約して、NTO 側のチームとそこで集合します。

NTO のビジネスユーザーは、Business Manager に必要なすべてのデータを更新するときに、「Managing the Storefront (ストアフロントの管理)」トレーニングで学んだ内容を実践します。このデータには、商品データ、画像、テキスト、プロモーション条件などが該当します。通常、これらのデータは顧客側が用意します。ただし、LRBC までにこうしたアセットを揃えておくことは常にあなたのチームの責任です。 

ブートキャンプが無事終了し、Mindy は NTO の熱心なチームに改めて感謝の念を抱きます。チームのお陰で立ち上げの用意ができました。このチームは列車での旅を楽しんでいます。そこで、テストも列車で行うことにします。

テストデータの収集

ストアフロントテストの中核をなすのは商品データです。テストデータの用意については NTO が全面的な責任を担います。NTO のデータは、実際の本番データを反映し、ありとあらゆるバリエーションを含むものである必要があります。極めて広範なテストシナリオを網羅するためには、こうしたバリエーションが欠かせません。テストデータの完全性を NTO と一緒に検証します。

テストケースの作成

テストフェーズを成功させるには、質の高い一連のテストケースも必要です。テストケースの作成には「全員参加」が求められます。パートナーであるあなたは、品質保証 (QA) とエンドツーエンドのテストケースに対する責任を担います。あなたの顧客である NTO は、ユーザー受け入れテスト (UAT) とシステム統合テスト (SIT) のテストケースに対する責任を担います。概して「顧客のビジネスについては顧客が一番よく知っている」と言いますが、テストフェーズにおいてはまさにそのとおりです。NTO の顧客、商品、買い物客によるストアフロントの操作について一番よく知っているのは NTO です。そしてもちろん、あなたのチームが NTO に協力することができます。NTO が UAT と SIT のテストケースをすべて準備できない場合には、あなたのチームが NTO の意見を聞きながらケースを準備することが考えられます。 

UAT や SIT のテストケースの作成において NTO をどの程度サポートするかはあなた次第です。Salesforce の経験上、チームと顧客が緊密に協力した場合に最もうまくいくことが判明しています。UAT と SIT のテストケースをあなたのチームが全面的に作成するプロジェクトでは、ケースが各機能にきちんと対処していることを顧客に確認してもらいます。テストフェーズを開始する前に、顧客のサインオフを取り付けます。

テスト計画の作成

テストケースは、どの機能をテストするかを指定するものです。また、テストフェーズをどのように進めるかを指定します。テストフェーズ限定のミニプロジェクト計画に、テストの戦略、目的、リソースの割り当て、スケジュール、成果物をまとめます。

テスト計画には次のカテゴリを設けます。

• エンタープライズリソースプランニング (ERP): すべてが設計どおり機能しているか?
  
• システムやサードパーティとの統合: サイトが他のシステムとうまく連携しているか?
  
• 注文管理システム (OMS) またはサービスレイヤー: 注文が最初から最後まで予想どおり処理されるか?
  
• ビジュアル: デザインが適切か?
  
• パフォーマンス: 高速列車より迅速か?
  

ストアフロントのテスト

プロジェクトの仕様に基づいてテスト計画を作成しました。極めて綿密なものであるべき仕様に、テストのあらゆるシナリオとデータのニーズが明記されていますよね? 当然のことと思うでしょうが、私たちの経験では、いくつかの領域が見落とされていることが少なくありません。ただし、今回は大丈夫です。Salesforce が、こうした計画で見落とされやすい領域のテストケースがきちんと記載されていることを確認します。 

検索エンジン最適化と分析

サイトが設定され、実際のデータが用意できたところで、いよいよ検索エンジン最適化 (SEO) を行います。NTO はこの機会に、SEO パートナーの実装が最新のエキスパートガイダンスに基づいていることを確認します。NTO はまた、SEO パートナーが作成した一連のテストケースをあなたに示します。

Alex がこの SEO のテストケースを計画に取り入れます。そして、メタタグ補完、画像の alt 属性の設定、SEO 対応 URL、サイトマップの調整など、SEO の一般的な要素がすべてケースに含まれていることを確認します。

オンサイト検索

オンサイト検索は、ユーザーが NTO のサイトに移動して商品をすばやく見つけられるようにするものです。テストケースでは、検索可能属性、辞書、カテゴリ名の除外などをチェックして、オンサイト検索の性能を試します。つまり、オンサイト検索が高い機能性と柔軟性を備えていることがわかります。

アクセシビリティ

Mindy は FSD にアクセシビリティの仕様も記録しています。実装がアクセシビリティ要件を満たしていることをテスターが検証します。Mindy が何らかの不安を抱いている場合には、Web アクセシビリティコンサルタントを雇うことも考えられます。

マーチャンダイジング

ここからは NTO のマーチャンダイジングチームが参加します。このチームは、カテゴリごとの並べ替えルールをテストします。たとえば、アパレルの色別の並べ替えを検証します。また、ユーザーグループごとに異なる画像を表示するコンテンツスロットの使用に関するシナリオを試します。 

負荷テスト

このプロジェクトで、NTO は負荷テストの実施をサードパーティに委託しています。サードパーティは、通常の条件下と予想されるピーク負荷の条件下でサイトの動作を確認します。NTO にテスト注文の別途の費用がかかることがないように、チームは Business Manager でサイトが「ライブ」とマークされる前に負荷テストを完了します。サイトがライブになった後で NTO が負荷テストを必要とした場合には、一時的なレンタルレルムを手配して使用します。この手配は、Salesforce B2C Commerce のカスタマーサクセスマネージャーがサポートします。 

問題の追跡

テストチームが一連のテストケースを実行中に、バグを見つけて選別します。バグを見つけるために虫捕り網は要りませんが、Bugzilla や Jira といった優れたバグ追跡ツールが必要です。このチームはバグツールを使用して、検出した問題をログに記録します。Alex と NTO のプロジェクトマネージャーが、立ち上げ前に修正しなければならない問題を特定して所有者を割り当て、期日を設定します。 

テストの成果物

• LRBC の完了
  
• すべての問題を追跡して選別したことを示すログ
  
• 立ち上げ前の修正がスケジュールされているすべての問題のリスト
  
• 立ち上げ後の修正がスケジュールされている問題のバックログリスト。
  

リソース

Trailhead Academy: Manage and Merchandise a B2C Commerce Cloud Store (B2C Commerce Cloud ストアの管理と商品販売)