モールからの受注取込で明細の一部が取り込まれず、受注が欠落する
モールごとに項目構成や締め時刻が異なるため、受注取込で明細の一部が欠落します。気づかず出荷指示が進むと、購入者への発送漏れとして表面化します。
GENZ, Inc.
EC基幹のテスト代行
EC一元管理システムの
EC基幹のテスト代行
EC一元管理システムのテストを、設計から報告まで代行します
モール追加や更改で増える接続先と業務シナリオの組み合わせ。受注取込から出荷連携までを単位にテスト設計を起こし、不具合票の管理と報告書の納品まで担います。
支援事例
支援実績5,000件以上
EC一元管理システムでよくある不具合
EC一元管理システムでは、モールやカートとの接続部、在庫引当の設定、SKU変換の定義に不具合が潜みやすく、リリース後に受注の欠落や在庫数量の不整合として表面化します。ここでは代表的な不具合を整理します。
モールからの
在庫引当が二重に行なわれ、同一SKUが複数チャネルで超過受注になる
同一SKUを複数チャネルで販売する場合、在庫の配分ルールによっては引当が二重に行なわれます。実在庫を超える受注が成立し、出荷遅延が生じます。
SKU変換の対応が一致せず、別商品として在庫数量が分かれて登録される
モール側の商品コードと自社のSKUの対応が一致しないと、同一商品が別SKUとして登録されます。在庫数量が分かれ、片側で欠品が生じます。
出荷実績が返却されず、発送通知が未送信のまま残る
倉庫やWMSからの出荷実績が返却されないと、モールへの発送通知が未送信のまま残ります。出荷は完了していても通知が届かず、問い合わせが増えます。
返品時の在庫戻しが反映されず在庫数が実在庫とずれる
返品やキャンセルで在庫戻しが反映されないと、システム上の在庫数と実在庫が一致しません。差異は棚卸まで判明せず、販売可能な在庫を把握できません。
残存した不具合により生じる問題
テスト項目書の作り直しや例外受注の属人化を放置したまま改修を重ねると、リリース後に表面化する不具合が現場の運用と経営の両方へ波及します。
静的テスト（レビュー）でおさえるべき観点
接続先の数だけ組み合わせが増えるEC一元管理では、画面操作の前に仕様書どうしの食い違いを特定することが、未検証の範囲を残さない出発点になります。照合の観点を先に固定します。
照合を省略すると項目の欠落を検出できず、受注データの取りこぼしがリリース直後に表面化するおそれがあります。
モール別の受注項目定義とAPI定義・CSVレイアウトの照合
モールごとに受注項目と締め時刻が異なるため、受注項目の定義書とAPI定義・CSVレイアウトを接続先ごとに照合し、項目の欠落や型の相違がないかを確認します。
確認する資料
- 受注項目定義書
- API定義書
- CSVレイアウト
変換漏れのまま引当が実行され、超過受注や在庫数量の不整合として出荷現場の手作業での対応に転嫁されるおそれがあります。
在庫引当ルールの仕様と商品マスタ・SKU変換表の照合
在庫引当の優先順位と按分ルールは標準機能の設定として決まるため、その仕様を商品マスタ・SKU変換表と照合し、変換漏れによる引当の不整合が起きないかを検証します。
確認する資料
- 在庫配分ルール
- 商品マスタ
- SKU変換表
更新順序の相違を見落とすと、同時実行で在庫が二重に引き当てられ、購入者への謝罪対応につながるおそれがあります。
DB設計書と受注・在庫テーブルの更新順序の照合
受注取込から在庫引当までの更新順序がDB設計書と一致しているかを照合し、同時に受注が入った場合でも在庫数量の不整合が起きないことを確認します。
確認する資料
- DB設計書
- テーブル定義書
- 更新順序定義
重複登録や取込漏れの条件が設計に反映されないままだと、売上計上の修正作業として経理側の負荷になるおそれがあります。
締め時刻・再送・重複登録の運用ルールと基本設計書の照合
モールごとの締め時刻と、再送・重複登録の運用ルールを基本設計書と照合し、二重取込や取込漏れが起きる条件が設計に反映されているかを確認します。
確認する資料
- 基本設計書
- 運用ルール
- 締め時刻一覧
権限の相違を見落とすと、権限外の操作で出荷実績や在庫が更新され、原因の切り分けに時間がかかるおそれがあります。
権限設定の仕様と部門・委託先の操作範囲の照合
物流部門や委託倉庫を含む部門ごとの操作範囲を権限設定の仕様と照合し、出荷実績の返却や在庫戻しが権限外の操作で行なえないことを検証します。
確認する資料
- 権限設定書
- 操作範囲表
- 部門権限表
- 委託先仕様書
動的テストの設計・実行のポイント
一元管理システムはモール・カート・WMSとの連携で成り立つため、単体の計算から受け入れ確認まで段階を分けて設計・実行します。
STEP 01
ユニットテスト境界値・同値分割で計算ロジックを確認
どう確かめるか
ユニットテスト: 在庫数量と金額の計算を境界値・同値分割で確かめる
在庫引当の優先順位や金額計算など、内部のロジックを境界値と同値分割で確認します。モールごとの締め時刻や在庫の按分ルールは設定値の境界で不具合が出やすく、計算結果の誤りを検出します。
- 01在庫数量の引当と按分の計算結果を境界値で確認します
- 02金額・税率の計算を同値分割の代表値で確認します
- 03SKU変換と項目マッピングの定義どおりの変換を確認します
OUTPUTテスト項目書と設計書
STEP 02
統合テスト接続先とのデータ授受を検証
どう確かめるか
統合テスト: モール・カート・WMSとのモジュール間の連携を接続試験で確かめる
モール・カートとのAPI連携とCSV連携、WMSへの出荷指示の受け渡しを接続試験で検証します。標準機能と個別対応の切り分けが曖昧になりやすいため、責任分界を送受信結果で確かめます。
- 01モールごとの受注取込の項目と締め時刻の違いを検証します
- 02API連携とCSV連携の切り分け箇所のデータ授受を検証します
- 03WMSへの出荷指示と出荷実績の返却を接続試験で確認します
OUTPUTテスト実施記録
STEP 03
システムテスト業務シナリオと異常系を通して検証
どう確かめるか
システムテストで受注から売上計上までの流れと異常系を確かめる
受注取込から引当・出荷指示・返品の在庫戻し・売上計上までを業務シナリオとして通し、分割出荷・ギフト指定などの例外の受注を発生させて検証します。属人化した手順もシナリオに組み込みます。
- 01受注から売上計上までの業務シナリオを通して検証します
- 02同梱・分割出荷・ギフト指定の例外の受注を発生させて検証します
- 03ピーク時の受注件数を前提にパフォーマンステストを実施します
OUTPUT不具合票と収束状況
STEP 04
受け入れテスト・回帰テスト本番相当データでデグレードを確認
どう確かめるか
受け入れテストと回帰テスト: 本番相当データでデグレードの有無を確かめる
本番相当データで受け入れを確認し、改修前後の比較でデグレードの有無を検証します。変更点が小さくても影響は受注から売上計上まで及ぶため、回帰テストの範囲を影響箇所から決めます。
- 01本番相当データで業務シナリオの受け入れを確認します
- 02改修の影響範囲から回帰テストの範囲を決めてデグレードを検証します
- 03不具合票の収束状況を整理し、リリース判断の材料を提出します
OUTPUT報告書とリリース判断材料
GENZが代行するEC一元管理システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 受注取込から売上計上までを網羅したテスト設計を起こせます
- 繁忙期前の実行工数を補い、検証を期日内に終えられます
- テスト項目書・実施記録・不具合票を監査に使える形で納めます
- モール側・提供事業者側・自社設定の原因を切り分けられます
業務の流れからテストを組み立てるGENZの支援
EC一元管理システムのテストで問われるのは、接続先と業務シナリオの組み合わせをどう区切るかの基準です。GENZは受注取込から出荷連携までの流れを単位にテスト設計を起こし、リリース判断に使える記録を納めます。
業務の流れを起点にテスト設計を組む
受注取込・在庫引当・出荷指示・実績返却の流れを単位にシナリオを組み、正常系と異常系の観点からテスト項目書へ展開します。
検証範囲と優先順位を見極める
接続するモール・カートとAPI・CSVの組み合わせを棚卸し、原因の切り分けが可能な単位で検証範囲の線引きと優先順位を言語化します。
既存のQA体制と開発日程に合わせて伴走
既存のQA体制を置き換えず、担当の分担を明示したうえで組み込みます。繁忙期前の実行工数の不足分を、開発日程に合わせて補います。
判断に使える試験記録と不具合票を納品
テスト項目書・実施記録・不具合票を、リリース判断とシステム監査の説明に使える形で納品します。残存する不具合と未検証の範囲も明示します。
ご相談から納品までの流れ
ご相談から報告書の納品まで、テスト設計・実行・不具合票の管理を第三者の視点で一貫して担います。
ヒアリングと検証範囲のすり合わせ
接続構成と運用ルールを確認し、検証範囲と優先順位をすり合わせます。
テスト設計と見積もりのご提示
テスト項目書の設計方針と必要工数を整理し、見積もりを提示します。
テストの実施と進捗・不具合の共有
テスト環境で項目を実行し、進捗と不具合票を共有して判断材料を出します。
報告書の納品と修正後の再確認
実施記録と不具合票をまとめた報告書を納品し、修正後の箇所を再確認します。
接続構成の棚卸しからご相談いただけます
EC一元管理システムの検証範囲と優先順位をGENZにご相談ください
新しいECモールへの接続改修や一元管理システムの更改をご検討中の企業様へ。検証範囲の区切り、優先順位、必要工数の考え方、回帰テストの要否まで、相談の場で整理してお示しします。