ECサイトのテスト観点｜事故りやすい9領域の確認項目

2026 8/17

2026年8月17日 2026年8月17日

ECサイトのテスト観点は、金額が実際に動き、在庫という有限資源を複数の利用者が同時に奪い合い、繁忙期にアクセスが集中するという性質から、汎用アプリより難しくなります。この3つが重なると、社内向けの業務システムでは起きにくい並行性や異常系の事故が本番で表面化します。兼任中心のQA運用では「正常に買えるか」の確認に時間が偏り、二重決済や在庫マイナスがリリース後に発覚しがちです。

ECサイトのテスト観点とは、金額計算・決済・在庫・異常系といった事故に直結する領域ごとに「何を確認すべきか」を洗い出した検証の切り口のことです。本記事はこの事故りやすい領域を9つに分け、観点に絞って整理しました。決済APIの実装コードや依頼設計そのものには踏み込まず、各セクションはこの記事だけで実行できる確認例を必ず残しています。汎用の観点出しから固めたい方は、テスト観点の洗い出し手順を体系的に整理した記事を先にご覧ください。

ECサイトのテスト観点はなぜ汎用アプリより難しいのか

EC特有の4大事故領域（金額計算・二重決済・在庫の同時実行・異常系）が実害に直結する構造を示すマップ

この領域が難しくなる理由は、扱う対象が「情報」だけでなく「お金」と「在庫」だからです。閲覧や検索が中心のサイトなら、多少の表示崩れは直せば済みます。しかしECでは、確認漏れがそのまま返金対応・在庫差異・クレームという実害に変わります。

ECには次の3つの特性があります。

金額が確定し、移動する：表示金額と実際に決済される金額がずれれば、過剰請求や取りこぼしになります
在庫という有限資源を奪い合う：同じ商品を複数の利用者が同時に買おうとすると、在庫の整合が崩れます
繁忙期に負荷が集中する：セールで同時アクセスが跳ね上がり、平常時に見えない不具合が顕在化します

ECの事故が実害に直結する理由

汎用的な業務システムなら、不具合の多くは社内での修正やデータ補正で吸収できます。一方でECの事故は、購入者という社外の相手に直接届きます。二重に請求すれば返金と謝罪が必要になり、在庫がないのに注文を受ければキャンセル連絡が発生します。

ECの不具合は「直せば済む」ではなく「謝って返金する」コストがかかるものです。だからこそ、正常系だけでなく異常系と並行性を最初から観点に組み込む必要があります。

品質を定量的に捉える視点も欠かせません。IPAが公開するソフトウェア開発分析データ集は、品質を数字で語る際の参考になります。個別のEC事故率を断定するのではなく、こうした客観的な指標を土台に、どこへテストを厚く配分するかを判断するのが実務的です。

4大事故領域の全体マップ

限られた工数で優先度を決めるなら、まず次の4領域を骨格にします。

事故領域	なぜ漏れるか	起こりうる実害
金額計算	割引・税・送料の組み合わせが多く、代表値だけでは端数や上限を見落とす	過剰請求／割引の二重適用／端数ズレ
二重決済	タイムアウトや再送は正常系のテストでは踏まない	2回課金／返金対応
在庫の同時実行	手動の単発操作では「同時」を自然には踏まない	在庫マイナス／売り越し／在庫切れ表示の遅延
異常系全般	失敗時の状態が仕様書に書かれにくい	宙ぶらりん注文／不整合ステータス

高橋寿一『知識ゼロから学ぶソフトウェアテスト』では、バグは特定箇所に偏る傾向が指摘されています。工数配分に迷ったら、まずこの4領域から着手するのが合理的です。この4つは、どのECサイトでも共通して事故の起点になりやすく、逆に言えばここを押さえるだけで実害の大部分を先回りして塞げます。

本記事の使い方

該当しない機能はスキップして構いません
各項目の「なぜ漏れるか」を読み、自案件で起きうるかを判断します
汎用技法が必要な箇所は、リンク先で補います

会員登録・ログイン・カートのテスト観点

入口となる状態管理の領域です。状態の崩れは、正常系だけを追うと気づけません。ここが崩れると、購入直前の離脱に直結します。

会員登録・ログインで確認する項目

会員登録とログインは、利用者が自分の情報を初めて預ける場面です。ここでの入力検証や状態保持が甘いと、購入にたどり着く前の段階で信頼を損ないます。まず次の項目を確認します。

入力検証（形式・文字数上限・記号・全角半角）が仕様どおりか
同一メールアドレスの二重登録を防止できるか
ログイン状態がページ遷移・再読込をまたいで保持されるか
パスワード再設定が別人のアカウントに影響しないか
未ログインでカート投入した商品が、ログイン後に引き継がれるか

これらが漏れると、同じメールアドレスで複数のアカウントが作られて注文履歴が分断したり、再読込のたびにログインが切れて利用者が離脱したりします。いずれも画面上はエラーが出ないため、正常系だけを追う運用では最後まで気づけません。

未ログイン時のカート内容がログイン後に消えるのは、購入直前離脱に直結する典型事故です。

カートで確認する項目

カートは購入金額が確定する直前の入口であり、数量の扱いが金額と在庫の両方に波及します。想定外の数量を意図的に流し込み、境界や異常入力で壊れないかを見ておく必要があります。

数量0で削除になるかエラーになるか（仕様どおりか）
マイナスや極端に大きい数量を弾けるか
購入上限を超えたときの制御が効くか
削除後に金額が正しく再計算されるか
在庫を超える数量の投入を防げるか

数量の境界を詰めずにいると、極端な数量で金額計算が破綻したり、在庫を超える注文を受け付けて後からキャンセル連絡に追われたりします。数量の上限・下限は、境界値分析の基礎と実践をまとめた記事の考え方が役立ちます。

セッションと同時操作

同じ利用者が複数のタブや端末を並行して使う場面は、実際の購入行動では珍しくありません。片方の操作がもう片方に矛盾なく反映されるかを、意図的に並行操作して確認します。

セッションタイムアウト後にカートを操作したときの挙動
別タブで同じカートを操作したときの矛盾
PCとスマホなど別端末で同時ログインしたときのカート整合

この記事だけで試すなら、2つのタブで同じカートを開き、片方で数量を変えてもう片方を更新するだけでも矛盾を発見できます。片方のタブで削除した商品が、もう片方では金額に残ったまま決済に進めてしまう、といった食い違いはこの手順で表面化します。Copeland『はじめて学ぶソフトウェアのテスト技法』は、状態と遷移の整理は図よりも状態遷移表のほうが抜け漏れなく体系的だと述べています。

在庫引当のテスト観点｜同時購入・在庫切れ・予約

在庫残1の商品を2人の利用者が同時購入したとき一方が成功し他方が在庫切れになる引当競合のタイミング図

在庫は有限で、複数の購入者が同じ1個を同時に奪い合う領域です。手動の単発操作ではこの「同時」を自然には踏まないため、本番で初めて破綻が表面化します。

在庫が減る・戻る境界

在庫は増減の境界で事故が起きやすく、とくに「残り1個」と「0個」の切り替わりが要注意です。買えた瞬間に在庫表示が追随するか、失敗やキャンセルで在庫が正しく戻るかを一つずつ追います。

残1を購入したら在庫0で「在庫切れ」表示になるか
在庫0の商品をカート投入・購入できないか
キャンセルで在庫が正しく戻るか
決済失敗で確保した在庫が解放されるか（塩漬けにならないか）

戻し処理が漏れると、決済に失敗した在庫が確保されたまま塩漬けになり、実在庫はあるのに「在庫切れ」で売れない機会損失につながります。逆に戻しすぎれば在庫が実態より多く見え、売り越しの原因にもなります。

同時実行を専用ツールなしで近似検証する

「同時」は負荷ツールがなくても、手作業でかなりの範囲まで近似検証できます。まず手元でできる範囲を押さえ、そこから先を専用ツールに委ねる、という線引きが現実的です。

在庫残1にして2ブラウザ／2端末で手動同時操作：購入ボタンをほぼ同時に押し、片方だけ成功し他方が在庫切れになるかを見ます
引当ログの目視確認：操作後に在庫数と引当レコードがマイナスや二重確保になっていないかを確認します
決済処理中の売り切れ：処理を挟んで在庫を先に減らし、確定前に在庫が再確認されるかを見ます

同時操作の観点	期待する結果
残1を2人が同時購入	一方が成功し、他方は在庫切れになる
同時購入	在庫がマイナスにならない
一方が購入・他方がカート投入中	購入時点で在庫を再チェックする
決済処理中に売り切れ	決済確定前に在庫を再確認し、売り越しを防ぐ

在庫のテストは「1人で正しく買えるか」ではなく「同時に買われたときに破綻しないか」を問うものです。ここまでは手作業で確認でき、より高い同時接続数での挙動は負荷ツールが必要になります。

予約・取り置き・カート投入の引当タイミング

カート投入や予約の時点で在庫を仮確保する仕様では、確保と解放のタイミングが噛み合わないと在庫が実態より少なく見えます。放置されたカートや期限切れの扱いを、仕様に照らして確認します。

カート投入時に仮確保する仕様なら、放置カートで在庫が枯渇しないか
予約商品と通常在庫を二重に確保していないか
仮確保の有効期限切れで在庫が戻るか

まず自案件の引当タイミング（いつ在庫を押さえるか）を確認することが出発点になります。ここが曖昧なままだと、在庫はあるのに買えない、あるいは買えたのに在庫がない、という双方向の事故が同時に起こり得ます。

決済のテスト観点｜二重決済・失敗・返金・タイムアウト

最も実害が大きい領域です。実装APIやコードには踏み込まず、「どんな状態になるべきか」に徹して観点を組み立てます。

正常系と主要な異常系

「正常系／異常系」は現場の慣用語です。標準用語で整理するなら、JSTQB 日本語サイトが定義する有効・無効な入力（有効同値・無効同値）や、あえて失敗させるネガティブテストの考え方が対応します。決済では、この無効入力と例外系こそが抜けやすい観点です。

決済完了で注文が確定するか
与信否認のときに注文が確定しないか
残高不足・カード期限切れ・限度額超過を正しく扱えるか
決済代行エラー時の表示と注文状態が仕様どおりか

「決済が失敗したときに注文がどの状態になるか」は、仕様書に書かれにくく最も抜けやすい観点です。

二重決済が起きる経路と確認項目

決済ボタンを二重クリックしても2回課金されないか
処理中にタイムアウトし、再送しても二重にならないか
完了画面で戻る・リロードしても再決済されないか
ネットワーク切断後に再接続したときの整合が取れるか
同一注文の再送でも、決済・注文が二重生成されないか（サーバ側の重複排除・冪等性）

専用ツールがなくても、決済ボタンの二重クリックはネット切断＋「戻る」操作で手再現できます。完了直後に回線を切り、戻ってもう一度送信して二重にならないかを見るだけで、多くの経路を確認できます。利用者は反応が遅いと無意識にボタンを連打するため、この経路は実際の現場で頻繁に踏まれます。

返金・キャンセル・部分返金と注文ステータス整合

返金やキャンセルは、金額・在庫・注文状態という3つの値を同時に動かす操作です。どれか一つでも取り残されると、経理や在庫の帳尻が合わなくなります。

全額返金後にステータスが「返金済み」になるか
部分返金で返金額と残額が正しく計算されるか
キャンセルで在庫が二重に戻らないか
出荷後キャンセルなど、状態による操作可否が制御されるか

金額・在庫・状態がずれると、経理・在庫・顧客対応に波及します。個別の画面だけでなく、返金からステータス反映、在庫の戻りまでを通しで整合を確認してください。

複数決済手段・分割支払いの組み合わせ

決済手段	特に見るべき観点
クレジットカード	与信（オーソリ）成功後に売上確定（キャプチャ）が失敗したときの注文状態と、在庫引当の解放が整合するか／期限切れ／二重決済
コンビニ	入金前後の注文状態／支払期限切れの扱い
後払い	与信落ち時の注文状態／請求書との整合
ポイント併用	充当後の請求額／返金時のポイント戻し

クレカの与信成功・売上確定失敗という中間状態は、宙ぶらりん注文を生む温床です。このとき在庫が確保されたまま残らないかを、必ずセットで確認します。決済手段が増えるほど中間状態のパターンも増えるため、扱う手段ごとに「失敗したらどこで止まるか」を明文化しておくと漏れを防げます。

クーポン・ポイント・金額計算のテスト観点

割引・クーポン・ポイント・送料・税で構成される金額計算の要素と端数が発生する箇所を示す図。順序と丸めは仕様で確定する

条件の組み合わせが爆発する領域です。代表値だけだと、端数・上限・併用の不整合を見落とします。

クーポン・ポイントの確認項目

割引やポイントは、条件が単独では正しくても、重ね合わせた瞬間に破綻することがあります。併用・上限・期限という条件を単体で確認したうえで、あえて同時に成立させ、金額が崩れないかを見ます。

クーポンの併用可否が仕様どおりか
利用上限・最低購入金額の判定が正しいか
有効期限切れの失効クーポンが使えないか
ポイント付与額の計算基準（税抜／税込どちらか）が正しいか
ポイント利用後のキャンセルで、ポイントが正しく戻るか

この組み合わせを詰めないと、本来併用できないクーポンが重なって想定より安く売ってしまったり、キャンセル時にポイントだけが戻らず顧客対応が発生したりします。

クーポンの「併用」「上限」「失効」の3条件が重なるケースは、代表値テストで必ず漏れるため、意図的に組み合わせて確認します。

送料・税・割引の計算順序と端数処理

計算順序（割引→税→送料など）や丸め方に「唯一の正解」はありません。内税か外税か、割引を税の前後どちらで適用するか、軽減税率をどの単位で丸めるかは、税制と仕様に依存します。したがって観点は、順序と丸めを仕様で先に確定し、テストでは「仕様で定義された順序・丸め規則への適合」を確認するという形にします。

確認する観点	見るべき内容
計算順序	仕様で定めた順序どおりに計算され、順序違いで金額がずれないか
端数処理	切捨・切上・四捨五入が仕様どおり統一されているか
内税／外税・割引の位置	税前割引・税後割引など仕様上の分岐を組み合わせて検証したか
軽減税率	税率ごとに、仕様で定めた端数処理単位で合算されているか
送料無料の境界	境界のちょうど・1円下・1円上で正しく判定されるか

端数処理は1件あたりわずかな差でも、注文数が積み上がると無視できない金額のズレになります。送料無料や割引適用の境目（ちょうど・1円下・1円上）は、境界値の考え方で必ず確認項目に含めてください。

条件の組み合わせを体系化する

併用可否や上限のように条件が絡み合う場合は、判定表（デシジョンテーブル）で条件と結果を整理すると漏れが見えます。条件を頭の中だけで組み合わせようとすると必ず抜けが出るため、表に落として網羅性を担保します。手順はデシジョンテーブルテストの進め方を解説した記事で確認できます。

注文フロー全体・配送・管理画面のテスト観点

画面単位ではなく、フローを通して見る領域です。1画面ずつ正常でも、つなぐと状態が壊れることがあります。

注文フロー通しの観点

注文フローは複数の画面をまたいで状態を持ち越すため、1画面ずつの確認では見えない事故が潜みます。利用者が実際に取りがちな「戻る・リロード・中断」を各画面で挟み、状態が壊れないかを通しで確認します。

各画面で「戻る」を押したとき、入力・状態が保持されるか
途中でリロードして二重注文や巻き戻りが起きないか
決済直前で中断し、再開したときに整合が取れるか
完了画面から再度、注文フローに戻れてしまわないか

フロー通しは「戻る・リロード・中断」の3操作をどこで挟んでも壊れないかを問うものです。

配送の確認項目

配送条件は、日時指定や送料の境界に仕様の分岐が集中します。指定できる日の端や、送料無料になる金額の境目で判定がずれないかを確認します。

配送日時指定の下限・上限（最短・最長・指定不可日）
送料無料の境界と地域別送料の合算
複数配送先での送料と在庫分割
一部入荷待ちの分割配送

境界を外すと、指定できないはずの日時が選べてしまい出荷側の運用が破綻したり、送料無料の判定が1円ずれて意図せず利益を削ったりします。複数配送先や分割配送は、送料と在庫が同時に分割されるぶん、整合の確認がとくに漏れやすい箇所です。

管理画面と顧客側データの整合

管理画面での操作は、顧客側の表示やデータと二重に整合していなければなりません。運用担当が受注や在庫を動かしたとき、フロント側が同じ状態を示すかを確認します。

管理画面の受注ステータス変更が顧客側表示に反映されるか
在庫調整とフロント側の在庫表示が一致するか
返品・キャンセル後の金額・在庫・注文状態が整合するか

ここがずれると、管理画面では発送済みなのに顧客側は未発送のまま、といった食い違いが問い合わせを生み、運用現場の信頼を損ないます。管理側とフロント側は別々にテストされがちですが、必ず両方を突き合わせて確認します。

繁忙期の同時アクセス・負荷のテスト観点

セールやタイムセールでは、同時アクセス集中により「在庫の同時実行事故」と「性能劣化」が同時に起こります。負荷テストの実施手順は安定したシステム運用の実践ガイドにまとめています。

想定すべき負荷シナリオ

繁忙期の負荷は平常時の延長ではなく、短時間に処理が集中する「スパイク」として現れます。どの瞬間にアクセスが跳ねるかを具体的に想定し、シナリオとして書き出しておきます。

セール開始直後の瞬間的なスパイク
人気商品・数量限定商品への集中
タイムセール終了間際のカート投入と決済の殺到

想定を持たずに本番を迎えると、セール開始の数秒で在庫と決済が同時に詰まり、平常時のテストでは一度も見なかった不具合が一斉に噴き出します。どの商品・どの時間帯に集中するかを事前に洗い出すことが、負荷観点の出発点です。

負荷時に顕在化する観点

負荷時の事故は、機能の不具合と性能の劣化が絡み合って表面化します。単独では問題なかった処理が、遅延と再送の連鎖で破綻に転じます。

観点	顕在化する事故
在庫の同時引当	在庫マイナス／売り越し
タイムアウト	注文が中途半端に残る
二重送信	レスポンス遅延で連打され、二重注文になる

繁忙期は「在庫の同時実行」と「性能劣化」が同時に牙をむくため、機能事故と性能事故を切り離さずに見ます。

性能劣化と機能事故の複合

性能の劣化は、それ単体で終わらず機能の事故を連れてきます。次のような連鎖は、負荷が高まったときに繰り返し観測されるパターンです。

レスポンス悪化 → 決済ボタン連打 → 二重決済
表示遅延 → 在庫切れ表示が間に合わない → 売り越し
タイムアウト → 再送 → 注文やメールの重複

いずれも起点は「反応が遅い」という性能の問題ですが、利用者の再操作を通じて二重決済や売り越しといった金銭・在庫の事故に化けます。だからこそ、性能と機能を別々のテストに分けず、一つの観点としてつなげて見る必要があります。

ECサイトのテスト観点を抜け漏れなく運用に落とすには

観点は一度きりで終わらせず、使い回せるチェックリストとして運用に落とすことで、ECサイトのテスト観点が組織の力になります。ここでは、送客に頼らずこの記事だけで着手できる形にまとめます。

そのまま使える4大領域テンプレート

工数が限られる場合は、まず次の表を項目書の骨格としてコピーして使ってください。各領域から最優先の1〜2観点だけを残せば、最小構成のチェックリストになります。

事故領域	最優先で確認する観点	なぜ確認するか
金額計算	仕様で定義した計算順序・丸め規則どおりか／送料無料の境界	過剰請求・取りこぼしを防ぐため
二重決済	二重クリック・再送・リロードで注文と決済が二重生成されないか（冪等性）	返金対応と信頼失墜を防ぐため
在庫の同時実行	残1の同時購入で在庫マイナス・売り越しが起きないか	クレームと機会損失を防ぐため
異常系	決済失敗・タイムアウト時の注文状態と在庫引当解放の整合	宙ぶらりん注文を防ぐため

観点を自案件のテスト項目書に落とす手順

上の4大事故領域を骨格にする
該当機能だけ残し、不要な項目を削る
固有仕様（引当タイミング・決済手段・配送条件）を追記する
各項目に「なぜ確認するか」を一言添える
出た不具合を観点に反映し、次案件へ引き継ぐ

Copeland『はじめて学ぶソフトウェアのテスト技法』も、一番役立つのは自組織の経験から作った分類だと述べています。既存の観点表を出発点に自案件で出た不具合を吸収して育てるのが定着の近道です。

工数が足りないときの最小実行セット

9領域すべては物量が多く、兼任では回りきりません。捨てる判断軸はシンプルで、「金銭が動くか」「在庫が減るか」を最優先に残すことです。時間がなければ、以下の「最低限これだけは」に絞ります。

二重決済（二重クリック・再送・リロード）
決済失敗時の注文状態と在庫引当の解放
残1の同時購入で売り越しが起きないか
送料無料・数量上限の境界

費用対効果は、上長への説明にそのまま使えます。本番で二重決済が起きれば、返金・問い合わせ対応・再発防止に工数が発生します。観点を1つ追加する手間と比べると、事後対応は割高になりやすい、という論理の型で優先度を伝えられます。数値を持ち出さずとも、「動いた金銭は必ず後始末が要る」という一点で優先順位は十分に説明できます。

体制の選択肢

決済・在庫の同時実行・負荷のように「同時」を再現する検証は、兼任中心のQA運用では手が回りにくい領域です。内製を強化するか、事故領域だけを部分的に外注するかという選択になります。依頼の設計はECサイトのテスト外注で依頼を組み立てる記事で扱っています。本記事の観点表は、内製・外注どちらでも確認範囲を共有する共通言語として使えます。