品質保証がファッションEコマースのコンバージョン率を向上させる方法

によるイベント Digital Fashion Academy
4月18th 2023

ここでウェビナーを見る:

概要

タイトル： ファッションEコマースにおけるコンバージョン率向上のための品質保証
DATE： 4月18日火曜日午後5時30分（ローマ中央ヨーロッパ時間）
期間： 1の時間
LANGUAGE： 英語
新規登録: ウェビナーは登録すると無料になります

概要

エンリコ・ファンタグッツィ（Digital Fashion Academy）とロレンツォ・ファネッティ（推測しない）が提示する ベストプラクティス の 品質管理 of e-commerce ファッションとラグジュアリー分野のサイト。

このウェビナーでは、 重要な概念 品質保証管理のため e-commerce プロジェクトから 標準 ラボレーション 大企業で使用されている サービスレベルアグリーメント 契約の定義時に開発機関と共有される SLA。

• 品質管理 は、 結果 プロジェクトの 期待 顧客 利用者 製品および 規格 によって必要とされる 規制.

• ファッションで e-commerce品質保証は、 保証 成功 サイトに関して 変換 率 とに コントロール プロジェクト コスト.

「多くの場合、 e-commerce サイト開発プロジェクトにおいて、多数の欠陥が発見され、プロジェクトの成功と開発者とクライアントの関係を損なうリスクがあることが問題となっています。適切な品質保証管理こそが、クライアントの満足、最高のユーザーエクスペリエンス、そしてクライアントとサプライヤーの関係の適切な管理を実現する鍵です。

エンリコ・ファンタグジー

トピックス

• 品質基準の定義 e-commerce ウェブサイト
• 納品後の製品保証
• 製品テスト方法論とバグ解決管理
• バグ追跡および問題追跡ツール

写し

このEラーニング会社を設立する前、私は小規模ブランドから大規模な多国籍企業、eテイラーに至るまで、ファッションや高級品を扱う企業で20年以上働いていました。

このウェビナーでは、私がファッションブランドで働いていた時代に学んだことのいくつかを皆さんと共有したいと思います。今日皆さんと共有する経験は、主にファッション業界以外、デジタル エンターテイメント分野で得たものです。

今日は、 品質保証の重要性 および なぜそれが成功に重要なのか ファッションの ecommerce. 

いくつかのアイデアと例をご紹介します。 社内で品質保証プロセスをどのように組織化するか 

最後に、あなたが心に留めておくべきいくつかのことについて説明します。 サプライヤー、開発者、システムインテグレーターと課題について話し合う、交渉中に何を尋ねるべきか、最終結果があなたの期待を満たすようにするために契約書に何を含めるべきか。 

ではファッションにおける品質保証の目的は何でしょうか？ e-commerce? 

品質保証の目的は何ですか?

品質保証の目的は、デジタル製品がクライアント（あなた自身）と、デジタル製品の最終ユーザー（顧客）の期待に応えていることを確認することです。 

エンリコ・ファンタグジー

もっと具体的に言うと 期待について話すとき、私たちは要件と仕様について話します要件と仕様は期待と異なるため、 1つ以上の文書に明確に記載され、文書化されている. 

さらに、以下の事項を遵守する必要があるかもしれません 法的制約により会社に拘束力のある要件.

3つ目に、書かれていない期待のセットがありますが、これらの期待のいくつかは、 経営陣や取締役会、その他の利害関係者の期待 何らかの形でプロジェクトに関わっています。 

要件と仕様とは何ですか?

要件と仕様とは何かをより明確に定義してみましょう。これらは皆さんにとって馴染みのある専門用語ですが、いくつか例を挙げて、例を通して頭に定着できるようにしたいと思います。

例 要件: 

• アカウントを作成する機能、 
• ゲストとしてチェックアウトできる 
• 一括払いではなく分割払いが可能 
• さまざまな配送オプションから選択可能 
• 検索時に特定のサイズのみをフィルタリングする機能、 
• 検索ツールでキーワードを検索する機能
• チェックアウトプロセス中に送料と税金が見える

例の仕様: 

• デバイスおよびオペレーティングシステムとの互換性 
• 画像、バナーのサイズ 
• システム間の周波数データ交換
• 1ページあたりの結果の形式と数

要件仕様と期待はどこに記載されていますか?

これらの要素は通常、1 つ以上のプロジェクト ドキュメントに書き込まれます。 

最も頻繁に使用される文書は 製品要件文書（PRDとも呼ばれる）これは通常、責任者であるマネージャーが所有し、作成します。 e-commerce プラットフォーム。製品要件ドキュメントが利用できない場合は 要件と仕様をプロジェクト計画に直接書き込むことができます最後に、品質仕様と要件の一部もここに記載されています。 品質計画. 

品質計画は主に品質テストと品質保証プロセス全般を体系化することを目的としていますが、デジタル製品の品質に関する具体的な要件も含まれる場合があります。例えば、品質計画には、実施が必要な具体的なセキュリティテストも含まれる場合があります。例えば、私が大手スポーツウェアブランドのサービスサプライヤーとして働いていたとき、 ecommerce ウェブサイトでは、クライアントのセキュリティ基準を満たすために、サーバーのセキュリティ テストを調整する必要がありました。 

範囲外のテスト

一方、品質計画では、プロジェクトの範囲外のテストが示される場合があります。例えば、オーストラリアに出荷する予定がない場合、 ecommerce特定の国向けの仕様を開発およびテストするために時間と労力を費やすべきではありません。 

ワイヤーフレームとコンポジション

品質計画では、仕様や要件について他のドキュメントを参照できます。たとえば、品質計画では、Web サイト全体のデザイン品質や外観に関連するすべてのものについて、ワイヤーフレームやコンポジション モックアップを参照できます。

これらのドキュメントは、開発者が開発や作業で達成する必要があるものの参照として使用されるので重要です。 

品質計画では、要件に加えて、実行する必要のあるテスト、プロジェクト中および製品の納品中にテストをいつ実行するか、またテストをどのように実行するかについて説明します。

GO-LIVE基準

品質計画にはGO-LIVE基準も含まれている必要があります。GO-LIVE基準とは、プロジェクトを稼働させるために満たすべき条件のセットであり、GO-LIVE基準の例は次のとおりです。 ライブウェブサイトで許可されるバグの最大数とその重大度例えば、品質計画では、プロジェクトが稼働開始する時点でウェブサイト上のバグ数が最大10個である場合にのみプロジェクトが稼働開始するように規定することができます。

最後に、品質計画には、テストの責任者と内容、バグ追跡ツールの使用方法、バグを重大度に応じて分類する方法など、品質保証プロセス中にプロジェクト チームが従う必要がある手順が含まれます。

どのような種類のテストを実行する必要がありますか?

品質保証テストの種類

それでは、ファッションブランドがどのようなテストに重点を置くべきかを詳しく見ていきましょう。

ファッション企業がコマース プラットフォームが期待どおりに動作していることを確認するために実行できるテストにはいくつかの種類があります。

煙のテスト

当学校区の スモークテストは、コア機能をチェックすることを目的としたシンプルなテストです。 デジタル製品のテストです。これらのテストは通常​​、開発者がプロ​​ジェクト中にソフトウェアのコア機能が動作することを確認するために行われます。プログラムのコア機能を試すだけの簡単なテストです。 プラットフォーム上でタスクを完了する必要がある通常のユーザーまたは潜在的な顧客をシミュレートする例えば、ウェブサイトにテキスト検索機能を実装する場合、スモークテストはブランドに関連するキーワード（例えば「赤い革のバッグ」）をいくつか入力し、結果が一貫しているかどうかを確認することです。この段階では、例えばグラフィックデザインは関連性がない可能性があります。目標は、一貫した結果を得ることです。「赤い革のバッグ」を検索して青いTシャツが表示された場合、スモークテストは失敗です。    

統合テスト

統合テストは特定のテストです あるシステムから別のシステムへのデータの正しい通過を確認する例えば、Eコマースプラットフォームから会社のERPへ、ERPから倉庫管理システムへ、あるいは ecommerceプラットフォームからビジネスインテリジェンスプラットフォームへの移行。データが損失なく、想定された時間内に、あるシステムから別のシステムに正しく渡された場合、このテストは成功とみなされます。 

ユーザー受け入れテスト

ユーザー受け入れテスト (UAT) は通常、クライアントと開発者が一緒に実行します。 

UAT 中に、クライアントは製品の検索、製品をウィッシュリストに追加、製品をウィッシュリストからカートに移動する、チェックアウト プロセスを完了するなど、考えられるすべてのユース ケースを実行して、すべてが期待どおりに機能していることを確認します。 

これらのテストは通常​​、開発フェーズの終盤、つまり製品がクライアントへの納品準備がほぼ整った時点で実施されます。通常、このテストの出力は、クライアントから要求され、開発者が修正するバグのリストとなります。

回帰テスト

4つ目のテストは回帰テストです。回帰テストは、コードの変更、更新、またはプラットフォーム上の他の機能のリリース後も、アプリケーションが期待どおりに機能することを確認します。回帰テストは、プラットフォーム全体の安定性を確保します。

これらのテストは、ウェブサイトに新しいリリースがあるたびに品質チームが実行する必要があります。、以前動作していたすべての機能が引き続き正常に動作していることを確認します。 

たとえば、新しい支払いシステムを開発していて、チェックアウトで分割払いを開発しているとします。この新しい機能の展開中に、以前は正常に動作していたクレジットカードの支払いが壊れてしまい、以前は動作していた機能にバグが導入されたことになります。この場合、回帰について話しています。

バグテストとバグ修正プロセス

 品質保証リーダーの役割について説明しました。次に、品質保証プロセスに関与するすべての関係者がどのように相互作用するかを見てみましょう。

最初のステップは、バグが最初に発見されたときに発生します。テスト担当者（プロジェクトチームのメンバー、またはテストスクリプトに従うプロフェッショナルテスター）がバグを発見します。例えば、テストスクリプトには「商品をウィッシュリストに追加し、その後、商品をウィッシュリストからショッピングカートに移動する」という内容が記述されます。 

テスターが製品をウィッシュリストに追加できない場合、または製品をウィッシュリストからショッピングカートに移動できない場合、テスターはバグを報告し、バグ追跡ツールでチケットを開きます。 テスターがシステムのバグを報告する場合、バグを再現するための手順などの仕様も追加する必要があります。これにより、開発者はバグが発見された状況を迅速に再現できるようになります。テスターは通常、バグ発見時に使用されていたデバイスとオペレーティングシステムについても報告します。例えば、私はiPad ProでSafariを使用していました。

2番目のステップでは、 QAリーダーはバグに関する入手可能なすべての情報を確認し、バグがまだ報告されていないことを再確認します。これは重要です。そうしないと、バグ追跡ツールにバグが重複してしまう可能性があります。

QAリーダーは、バグをチームメンバーに割り当て、問題解決に取り組みます。なお、ここでは「バグ」と「問題」を同義語として使用していることに注意してください。

ステップ 3 では、開発者は開発環境で問題を修正し、問題を修正済みとしてマークします。 

開発者はバグを「修正済み」または「解決済み」としてマークしますが、バグ追跡ツールでチケットをクローズしないことに注意してください。バグを報告した人または QA リーダーのみが、問題をクローズ済みとしてマークする必要があります。

最後のステップでは、バグを報告した人または QA リーダーが、プラットフォーム上でバグが実際に修正されたことを確認し、バグ追跡ツールで問題が解決済みとしてマークされます。

UATテスト手順の概要

1. テスターはウェブサイト上でタスクを完了しようとします。例えば、商品をウィッシュリストに追加するなどです。
2. テスターがタスクを完了できない場合は、バグ追跡ツールでバグを報告します。
3. QAリーダーはバグを検証します。つまり、そのバグがすでに他の誰かによって報告されていないことを確認します。
4. QAリーダーはバグをチームメンバーに割り当てて修正させる
5. チームメンバーはバグに取り組み、問題が解決したら修正済みとしてマークします。
6. QAリーダーまたはテスターは、機能が動作するかを確認するために再度テストします。
7. バグは最終的にQAリーダーまたはテスターに​​よってクローズされます

スピーカー