CONTENT
ここから
第22章では、ECで起きるエラー処理と障害対応について学びました。
決済リンク作成失敗、Webhook未着、在庫更新失敗、メール送信失敗、二重注文など、実務ではさまざまなトラブルが起きます。
この章では、本番公開前に行うべきテスト戦略を整理します。
ECでは、画面がきれいに表示されるだけでは不十分です。
本当に確認すべきなのは、次の流れが安全に動くかです。
商品を見る
↓
カートに入れる
↓
決済する
↓
Webhookを受け取る
↓
注文をpaidにする
↓
在庫を減らす
↓
メールを送る
↓
管理画面で確認する
↓
発送処理する
Squareには、実際のお金を動かさずに注文や決済などを試せるSandbox環境があります。また、Sandbox用のテストカードや支払いトークンも公式に用意されています。(Square)
第23章はいわば、「本番に出る前の最終訓練ステージ」です。
23.1 ECで必ずテストすべき項目
ECでテストすべき項目は、大きく分けると次の7つです。
1. 商品表示
2. カート
3. 決済
4. Webhook
5. 在庫
6. メール通知
7. 管理画面
まず、購入者側の画面を確認します。
・トップページが表示されるか
・商品一覧が表示されるか
・商品詳細が表示されるか
・価格が正しく表示されるか
・在庫切れ表示が出るか
・購入ボタンが押せるか
・スマホで見づらくないか
次に、購入処理を確認します。
・カートに商品を追加できるか
・数量変更できるか
・削除できるか
・送料が正しく計算されるか
・合計金額が正しいか
・Squareの決済画面へ進めるか
さらに、決済後の裏側処理を確認します。
・Webhookを受け取れるか
・注文ステータスがpaidになるか
・在庫が減るか
・注文完了メールが届くか
・管理者通知が届くか
・管理画面に注文が表示されるか
ECで大切なのは、画面単体ではなく、流れ全体を確認することです。
商品ページだけOK
では不十分
購入から管理画面までOK
なら安心
最初に作るテスト表は、次のような形で十分です。
テスト項目：
商品を購入できる
手順：
商品詳細を開く
購入ボタンを押す
Squareで決済する
完了ページを確認する
期待結果：
注文がpaidになる
在庫が1減る
メールが届く
管理画面に表示される
テストは、開発者だけでなく、実際に運用する店舗スタッフにも触ってもらうと効果的です。
開発者が気づかない使いにくさが見つかることがあります。
23.2 Square Sandboxで決済を試す
本番決済を試す前に、必ずSquare Sandboxでテストします。
Sandboxとは、テスト用の環境です。
実際のお金を動かさずに、決済やWebhookの動きを確認できます。
Sandbox：
テスト用
Production：
本番用
SquareのSandboxでは、テストカード番号や支払いトークンを使って、決済処理をシミュレーションできます。(Square)
Sandboxで確認する基本項目は、次の通りです。
・Sandbox Access Tokenを使っているか
・Sandbox Location IDを使っているか
・決済リンクを作成できるか
・テストカードで決済できるか
・WebhookがSandboxから届くか
・注文ステータスが更新されるか
まず、環境変数を確認します。
SQUARE_ENVIRONMENT=sandbox
SQUARE_ACCESS_TOKEN=sandbox_xxxxx
SQUARE_LOCATION_ID=xxxxx
本番用のTokenをテスト環境に入れてはいけません。
悪い例：
ローカル開発でProduction Tokenを使う
よい例：
ローカル開発ではSandbox Tokenだけ使う
Sandbox決済の流れは次の通りです。
商品を選ぶ
↓
購入ボタンを押す
↓
Square Sandboxの決済画面へ進む
↓
テストカードで支払う
↓
完了ページへ戻る
↓
Webhook処理を確認する
Sandboxで確認すべきポイントは、決済画面が出ることだけではありません。
決済後に、自前EC側が正しく反応するかを見ます。
Squareでは決済成功
↓
自前DBの注文はpaidになったか
↓
在庫は減ったか
↓
メールは送信されたか
↓
管理画面に表示されたか
Sandboxで一通り確認できてから、本番環境へ進みます。
23.3 正常系テスト
正常系テストとは、想定通りに購入が完了する流れを確認するテストです。
まずは、もっとも基本の成功パターンを確認します。
商品を見る
↓
カートに入れる
↓
決済する
↓
注文完了
↓
メールが届く
↓
管理画面に表示される
正常系テストで確認する項目は、次の通りです。
・商品詳細ページが表示される
・価格が正しい
・在庫がある
・購入ボタンが押せる
・決済リンクが作成される
・Square決済画面へ移動できる
・決済完了ページへ戻る
・Webhookが届く
・注文ステータスがpaidになる
・在庫が減る
・注文完了メールが届く
・管理者通知が届く
・管理画面に注文が表示される
1商品だけではなく、複数パターンを試します。
・単品商品
・複数個購入
・複数商品購入
・送料あり
・送料無料
・ギフト商品
・店頭受け取り
・催事受け取り
正常系テストでは、注文前と注文後の状態を記録しておくと分かりやすいです。
注文前：
在庫 10個
注文内容：
2個購入
注文後：
在庫 8個
期待結果と実際の結果を比べます。
期待：
在庫が2個減る
実際：
在庫が2個減った
結果：
OK
正常系テストは、ECの基本動作確認です。
ここが通らない状態で、例外処理や本番公開に進んではいけません。
23.4 決済失敗テスト
正常系だけでは不十分です。
ECでは、決済が失敗することもあります。
決済失敗時に画面や注文ステータスが正しく処理されるか確認します。
決済失敗の原因には、次のようなものがあります。
・カードが拒否される
・入力情報が不正
・ユーザーが決済をキャンセルする
・Square APIがエラーを返す
・決済リンク作成に失敗する
・通信が途中で切れる
テストで確認したいのは、失敗したときに注文を成功扱いしないことです。
決済失敗
↓
注文はpaidにしない
↓
在庫を減らさない
↓
注文完了メールを送らない
失敗時のステータス例です。
pending:
決済待ち
failed:
決済失敗
cancelled:
ユーザーがキャンセル
画面表示も確認します。
決済を完了できませんでした。
恐れ入りますが、内容をご確認のうえ、再度お試しください。
開発者向けのエラーをそのまま表示してはいけません。
悪い表示：
CreatePaymentLink failed: invalid token
よい表示：
決済画面を準備できませんでした。
決済失敗テストでは、次のことを確認します。
・注文がpaidになっていない
・在庫が減っていない
・注文完了メールが送られていない
・管理画面で失敗注文として確認できる
・再試行できる
決済失敗時に購入者が迷わないことも大切です。
もう一度試す
別の商品を見る
問い合わせる
このような導線を用意します。
23.5 Webhookテスト
Webhookテストは、決済完了後の裏側処理を確認する重要なテストです。
SquareのWebhookは、Squareアカウントでイベントが発生したときに、指定したURLへ通知を送る仕組みです。(Square)
Webhookで確認することは、次の通りです。
・Webhook URLが正しいか
・Squareから通知が届くか
・署名検証が通るか
・イベント種別を判定できるか
・同じevent_idを二重処理しないか
・注文ステータスが更新されるか
・在庫が減るか
・メール送信へ進むか
Webhookテストの基本フローです。
Sandboxで決済する
↓
SquareからWebhookが届く
↓
Route Handlerで受け取る
↓
署名検証する
↓
payment.updatedを処理する
↓
注文をpaidにする
Webhookでは、署名検証が重要です。
署名検証に失敗したWebhookは、処理してはいけません。
署名検証OK
→ 処理する
署名検証NG
→ 処理しない
SquareにはWebhook subscriptionをテストするAPIも用意されており、指定した通知URLへテストイベントを送る用途で使えます。(Square)
ただし、テストイベントだけでは実際の決済後処理を完全に確認できない場合があります。
そのため、次の2種類を試すと安全です。
1. Webhookテスト送信
2. Sandbox決済から発生する実Webhook
Webhookで特に重要なのは、重複処理です。
同じWebhookが複数回届いても、在庫やメール処理が二重にならないか確認します。
同じevent_idが2回届く
↓
1回目だけ処理
↓
2回目はスキップ
Webhookテストは、ECの裏側の心臓部です。
画面上は見えませんが、必ず確認します。
23.6 在庫切れテスト
在庫切れテストでは、商品が売り切れたときに正しく処理されるか確認します。
在庫管理が弱いと、売ってはいけない商品を売ってしまいます。
在庫0
↓
購入できてしまう
↓
決済完了
↓
商品を発送できない
在庫切れテストで確認する項目は、次の通りです。
・在庫0の商品に売り切れ表示が出るか
・購入ボタンが無効になるか
・カート追加できないか
・決済前に在庫を再確認しているか
・在庫不足時に在庫を減らさないか
・手動確認に回せるか
在庫切れ商品の画面表示例です。
現在、こちらの商品は売り切れです。
再入荷が決まり次第、こちらのページでご案内いたします。
購入ボタンは、押せない状態にします。
[売り切れ]
ただし、画面でボタンを無効にするだけでは不十分です。
決済前にも、サーバー側で在庫を確認します。
画面では在庫あり
↓
別の人が購入
↓
在庫0
↓
自分も購入ボタンを押す
この場合：
サーバー側で在庫不足として止める
在庫切れ時のサーバー側処理です。
商品IDと数量を受け取る
↓
DBで現在在庫を確認する
↓
在庫不足なら決済リンクを作らない
↓
画面に案内を返す
在庫切れテストでは、表示とサーバー処理の両方を確認します。
見た目：
購入できない
裏側：
決済も作れない
この2つがそろって、在庫切れ対策になります。
23.7 同時購入テスト
同時購入テストは、在庫が少ない商品で特に重要です。
たとえば、在庫1個の商品を2人が同時に購入しようとするケースです。
在庫：1個
Aさんが購入
Bさんも同時に購入
両方成功してしまうと在庫が足りない
同時購入テストで確認することは、次の通りです。
・在庫数を超えて購入できないか
・在庫更新が安全に行われるか
・片方だけ成功し、もう片方は止まるか
・失敗した注文がmanual_reviewになるか
・在庫がマイナスにならないか
同時購入を完全に再現するのは難しいですが、テスト方法はあります。
・ブラウザを2つ開く
・同じ商品を同時に購入する
・在庫1の商品で試す
・Webhook処理を短時間で複数回発生させる
・テスト用スクリプトで同時リクエストを送る
重要なのは、在庫更新を条件付きで行うことです。
UPDATE products
SET stock = stock - 1
WHERE id = 'product_id'
AND stock >= 1;
更新件数が0件なら、在庫不足です。
更新成功：
購入成功
更新0件：
在庫不足
manual_reviewまたは購入不可
テスト後に、在庫がマイナスになっていないか確認します。
悪い結果：
在庫 -1
よい結果：
在庫 0
片方のみ成功
同時購入は、小規模ECでも起きます。
特に限定商品、催事商品、一点ものでは必ずテストします。
23.8 管理画面テスト
管理画面は、店舗側が毎日使う画面です。
購入者向け画面だけでなく、管理画面も必ずテストします。
管理画面で確認する項目は、次の通りです。
・ログインできるか
・ログインしていない人が入れないか
・注文一覧が表示されるか
・注文詳細が表示されるか
・ステータス変更できるか
・発送済みにできるか
・追跡番号を登録できるか
・メール再送できるか
・CSV出力できるか
・権限のない操作ができないか
認証テストでは、次を確認します。
未ログイン：
管理画面に入れない
staff：
発送処理はできる
価格変更はできない
admin：
すべて操作できる
ステータス変更テストでは、許可されていない変更ができないか確認します。
よい流れ：
paid → preparing → shipped
危険な流れ：
pending → shipped
画面上でボタンがないだけでは不十分です。
サーバー側でも拒否されるか確認します。
画面：
ボタンを非表示
サーバー：
不正な更新リクエストを拒否
管理画面テストでは、実際の店舗スタッフにも触ってもらうと効果的です。
注文を見つけやすいか
次に何をすればよいか分かるか
ボタン名が分かりやすいか
誤操作しそうな場所がないか
管理画面は、開発者が使う画面ではありません。
店舗が迷わず使えるかを確認します。
23.9 E2Eテスト
E2Eテストとは、End to Endの略です。
最初から最後まで、実際のユーザーの流れに近い形で確認するテストです。
ECのE2Eテストでは、次のような流れを確認します。
トップページを開く
↓
商品一覧を見る
↓
商品詳細を見る
↓
カートに入れる
↓
決済へ進む
↓
決済完了
↓
注文完了ページを見る
↓
メールを確認する
↓
管理画面で注文を確認する
E2Eテストの目的は、部品単体ではなく、全体の流れが壊れていないか確認することです。
商品ページ単体：
OK
決済単体：
OK
Webhook単体：
OK
でも全体でつなぐと失敗することがある
そのため、必ず通しで試します。
E2Eテストで確認する代表的なシナリオです。
・通常商品を1個購入する
・複数商品を購入する
・送料無料条件を満たす
・在庫切れ商品を購入しようとする
・店頭受け取りを選ぶ
・催事受け取りを選ぶ
・決済をキャンセルする
・管理画面で発送済みにする
E2Eテストは、手動でもできます。
最初は手動で十分です。
テスト担当者が購入者役になる
↓
実際に画面を操作する
↓
期待通りに進むか確認する
慣れてきたら、自動テストツールを使う方法もあります。
ただし、小規模ECでは、まず手動で重要シナリオを確実に確認することが大切です。
最初：
手動E2Eテスト
運用が増えたら：
自動E2Eテスト
E2Eテストは、本番前の総仕上げです。
購入者、Square、自前DB、メール、管理画面がつながっているか確認します。
23.10 本番公開前チェックリスト
最後に、本番公開前のチェックリストを作ります。
本番公開前は、気持ちが急ぎやすいタイミングです。
しかし、ECでは本番公開後に実際のお金が動きます。
そのため、公開前に必ず確認します。
本番公開前
↓
チェックリスト確認
↓
テスト決済
↓
管理画面確認
↓
公開
基本チェックです。
・商品ページが表示される
・商品価格が正しい
・在庫数が正しい
・送料計算が正しい
・購入ボタンが動く
・スマホで購入できる
・商品画像が表示される
・特定商取引法ページがある
・プライバシーポリシーがある
・返品・キャンセルポリシーがある
Square関連のチェックです。
・本番用Access Tokenを設定している
・本番用Location IDを設定している
・Sandbox Tokenが本番に残っていない
・Webhook URLが本番URLになっている
・Webhook署名検証が有効
・本番決済テストを少額で行った
注文処理のチェックです。
・注文がpendingで作られる
・決済完了後にpaidになる
・Webhookログが残る
・在庫が減る
・二重処理されない
・manual_reviewに回せる
メールのチェックです。
・注文完了メールが届く
・管理者通知が届く
・発送完了メールが届く
・送信元メールアドレスが正しい
・迷惑メールに入りにくい設定になっている
管理画面のチェックです。
・ログインできる
・未ログインでは入れない
・注文一覧が見える
・注文詳細が見える
・ステータス変更できる
・追跡番号を登録できる
・CSV出力できる
・権限のない操作はできない
障害対応のチェックです。
・ログを確認できる
・Webhook未着時の対応手順がある
・メール送信失敗時の再送手順がある
・在庫不足時の対応手順がある
・手動確認フローがある
・問い合わせ先が明記されている
本番公開前の最終確認では、実際の購入者の目線で通し確認します。
初めてサイトを見る
↓
商品を探す
↓
購入する
↓
メールを受け取る
↓
安心できるか確認する
本番公開前チェックリストは、ECを安全に公開するための最後の防波堤です。
第23章のまとめ
ECのテストでは、画面表示だけでなく、購入から管理画面までの流れ全体を確認することが重要です。
この章で覚えておきたいポイントは、次の通りです。
1. ECでは、商品表示、カート、決済、Webhook、在庫、メール、管理画面をテストする
2. Square Sandboxで実際のお金を動かさずに決済を試す
3. 正常系では、購入完了までの基本ルートを確認する
4. 決済失敗時には、paidにしない、在庫を減らさない、メールを送らない
5. Webhookでは、署名検証、イベント種別、重複処理を確認する
6. 在庫切れでは、画面とサーバーの両方で購入を止める
7. 同時購入では、在庫がマイナスにならないか確認する
8. 管理画面では、認証、権限、ステータス変更を確認する
9. E2Eテストでは、購入者の流れを最初から最後まで試す
10. 本番公開前チェックリストで、公開してよい状態か確認する
テストの基本は、次の一言にまとめられます。
売れるかではなく、安全に売れるかを確認する。
商品が表示されるだけでは足りません。
決済できる。
Webhookが動く。
在庫が減る。
メールが届く。
管理画面で処理できる。
ここまで確認して、ようやく本番公開に進めます。
第24章では、いよいよ本番公開と運用について整理していきます。