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

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

ウェビナーはこちらでご覧ください:

概要

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

まとめ

エンリコ・ファンタグッツィ（デジタルファッションアカデミー) とロレンツォ・ファネッティ (推測しない）が ベストプラクティス のために 品質管理 ファッションおよび高級品分野の電子商取引サイト。

ウェビナーでは、 重要な概念 電子商取引プロジェクトにおける品質保証管理については、 標準 プロセス 大企業で使用されている サービスレベル契約 契約の定義中に開発機関と共有される SLA。

• 品質保証 は、 結果 プロジェクトの 期待 の お客様、 エンドユーザー 製品および 基準 によって要求される 規則.

• ファッションの電子商取引では、品質保証は 保証 成功 サイトに関して 変換 レート そして コントロール プロジェクト 費用.

「eコマースサイト開発プロジェクトの最後には、プロジェクトの成功と開発者とクライアントの関係を損なうリスクのある多数の欠陥が見つかることがよくあります。品質保証を適切に管理することで、クライアントの満足、最高のユーザーエクスペリエンス、クライアントとサプライヤーの関係の適切な管理が可能になります。」

エンリコ・ファンタグッツィ

トピックス

• 電子商取引サイトの品質基準の定義
• 納品後の製品保証
• 製品テスト方法論とバグ解決管理
• バグ追跡および問題追跡ツール

トランスクリプト

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

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

今日は、 品質保証の重要性 そして なぜそれが成功に重要なのか ファッション電子商取引の。 

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

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

では、ファッション電子商取引における品質保証の目的は何でしょうか? 

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

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

エンリコ・ファンタグッツィ

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

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

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

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

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

例 要件: 

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

例の仕様: 

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

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

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

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

品質計画は、主に品質テストと品質保証プロセス全般を整理することを目的としていますが、デジタル製品の品質に関する特定の要件も含めることができます。たとえば、品質計画は、実行する必要がある特定のセキュリティ テストを参照できます。たとえば、大手スポーツウェア ブランドのサービス サプライヤーとして働いていて、そのブランドの e コマース Web サイトを開発していたとき、クライアントのセキュリティ基準を満たすために、サーバー上のセキュリティ テストを調整する必要がありました。 

範囲外のテスト

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

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

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

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

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

GO-LIVE基準

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

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

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

品質保証テストの種類

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

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

スモークテスト

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

統合テスト

統合テストは、特定のテストです あるシステムから別のシステムへのデータの正しい通過を確認するたとえば、電子商取引プラットフォームから会社の ERP へ、ERP から倉庫管理システムへ、または電子商取引プラットフォームからビジネス インテリジェンス プラットフォームへなどです。データが 1 つのシステムから別のシステムに、データ損失なく、想定された時間枠内に正しく渡された場合、このテストは成功したと見なすことができます。 

ユーザー受け入れテスト

ユーザー受け入れテスト (UAT) は通常、クライアントと開発者の立ち会いのもとで実行されます。 

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

これらのテストは通常、開発フェーズの終わり近く、製品がクライアントに提供される準備がほぼ整ったときに行われます。通常、このテストの出力は、クライアントが要求し、開発者が修正するバグのリストです。

回帰テスト

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

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

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

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

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

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

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

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

QA リーダーは、そのバグをチーム メンバーに割り当てて、問題に取り組みます。現時点では、バグと問題を同義語として使用していることに注意してください。

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

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

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

UAT テスト手順の概要

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

スピーカー