تست فروشگاه اینترنتی؛ از Catalog تا Order، Fulfillment و Return

دو مشتری آخرین واحد یک کالا را تقریباً هم‌زمان می‌خرند. هر دو صفحه «سفارش ثبت شد» می‌بینند، Callback پرداخت دوبار می‌رسد، دو Job ارسال ساخته می‌شود و چند دقیقه بعد یک Event قدیمی موجودی، محصول را دوباره In Stock نشان می‌دهد. هیچ خطای ۵۰۰ رخ نداده است؛ بااین‌حال فروشگاه Oversell، Fulfillment تکراری و وعده موجودی غلط دارد. تست فروشگاه اینترنتی باید این زنجیره را ببیند، نه فقط Buttonها را.

در این راهنما، Journey تجارت الکترونیک را از Catalog و Variant تا Offer، Cart، Quote، Checkout، Order، Inventory Reservation، Payment، Fulfillment، Delivery، Cancellation، Return و Refund به Contract و Evidence تبدیل می‌کنیم. یک آزمایش کاملاً ساختگی نیز نشان می‌دهد چرا Snapshot ساده موجودی و Callback بدون Deduplication برای سفارش قابل اتکا نیست.

مرز ادعا: تست می‌تواند رفتار Build و Scope مشخص را با Oracle نسخه‌دار مقایسه کند؛ تجربه بی‌نقص، افزایش Conversion، فروش، وفاداری، امنیت، انطباق یا نبود Oversell را تضمین نمی‌کند. قیمت‌گذاری، موجودی، مالیات، ارسال، مرجوعی، حریم خصوصی، امنیت و قوانین بازار باید توسط صاحبان صلاحیت محصول و حوزه قضایی تعیین شوند. مثال‌های این مقاله داده واقعی، توصیه حقوقی یا قاعده عمومی تجارت نیستند.

خلاصه عملی تست فروشگاه اینترنتی

پرسش	شاهد ضعیف	شاهد بهتر
آیا محصول قابل خرید است؟	PDP باز می‌شود	Variant/Offer معتبر، Price و Availability تازه، Eligibility و Fulfillment روشن‌اند
آیا سبد درست است؟	Badge عدد را نشان می‌دهد	Line identity، quantity، price snapshot، merge و expiry Contract آزموده شده‌اند
آیا Checkout موفق است؟	Success page	Quote پذیرفته، Order یکتا، Reservation، Payment state و downstream effects reconcile شده‌اند
آیا موجودی درست است؟	عدد Database غیرمنفی است	On-hand/available/reserved/safety stock، concurrent reservations و release/expiry سازگارند
آیا ارسال انجام شد؟	Job ساخته شد	هر Fulfillment group یکتا، قابل پیگیری و با Order lines/Reconciliation منطبق است
آیا Release آماده است؟	Happy Path و Pass rate	Critical journey invariants، failure/recovery، Unknown، monitor و owner ثبت شده‌اند

ابتدا مدل کسب‌وکار را مشخص کنید

Ecommerce فقط فروش یک کالای فیزیکی از یک انبار نیست. Marketplace، کالای دیجیتال، Subscription، Preorder، Click-and-collect، چندفروشندگی، B2B، خدمات رزروی و فروش بین‌المللی Contractهای متفاوت دارند. Test plan عمومی بدون مدل عملیاتی، مسیرهای مهم را پنهان می‌کند.

مدل	ریسک محوری	Invariant نمونه	Owner نمونه
کالای فیزیکی	موجودی، انبار، ارسال، مرجوعی	هر line به Fulfillment قابل انجام نگاشت شود	Commerce/Inventory/Operations
کالای دیجیتال	Entitlement، download، revoke	دسترسی فقط برای Order state مجاز	Product/Entitlement
Subscription	Renewal، proration، cancellation	Term و charge schedule نسخه‌دار	Billing/Product/Legal
Marketplace	Seller، split order، commission، dispute	مالک هر Offer/line/fulfillment روشن	Marketplace/Finance/Trust
Preorder/Backorder	وعده آینده و تغییر ETA	Availability و promise type صریح	Merchandising/Supply
Pickup/Omnichannel	موجودی Location و handoff	Store/slot/reservation identity ثابت	Retail/Store Operations

صفحه ۱۸۱۶ دقیقاً مالک چه Intentی است؟

این صفحه مالک تست Lifecycle سفارش تجارت الکترونیک است: Catalog → Cart → Quote → Checkout → Order → Inventory → Fulfillment → Return. جزئیات Money/Ledger/Reconciliation مالی در راهنمای تست نرم‌افزار مالی و اتصال IPG در راهنمای تست درگاه پرداخت عمیق‌تر پوشش داده شده‌اند.

Performance، Security، Usability، Accessibility، Compatibility و Localization برای فروشگاه ضروری‌اند، اما صفحات تخصصی خود را دارند. اینجا آن‌ها را به Journey وصل می‌کنیم تا هم‌نوع‌خواری محتوایی و Checklist بی‌مالک ساخته نشود.

Commerce Context Contract بنویسید

Commerce Context Contract
Business model:       [retail/marketplace/digital/subscription/...]
Channels:             [web/app/store/call-center/feed]
Markets/locales:      [approved scope]
Customer modes:       [guest/member/B2B/...]
Catalog sources:      [product/variant/offer authorities]
Price sources:        [rules, currency and quote policy]
Inventory sources:    [location, reservation and freshness]
Order source of truth:[states and ownership]
Payment boundary:     [intent/auth/capture/settlement references]
Fulfillment boundary: [warehouse/seller/carrier/digital]
Return/refund policy: [version and applicability]
Partner contracts:    [API/event/feed versions]
Excluded journeys:   [explicitly out of scope]
Release identities:  
Evidence owners:      [roles and decisions]

عبارت «خرید موفق» را در Contract نشکنید. ممکن است Order ایجاد، موجودی Reserve و Payment Authorized شده باشد اما Fulfillment هنوز ممکن نباشد. برای هر Stage، source، state، ID، side effect و کاربر/عملیات مسئول را بنویسید.

شناسه‌ها را از نام و URL جدا کنید

Product، Variant، SKU، Offer، Seller، Location، Cart، Quote، Order، Order line، Reservation، Payment، Fulfillment، Shipment، Return و Refund یک شناسه نیستند. استفاده از title، slug یا index آرایه به‌عنوان Identity می‌تواند تغییر Variant، ترجمه یا reorder را به کالای دیگری وصل کند.

Entity	Identity	Version/State	رابطه حیاتی
Product	productId	content/version	has variants
Variant/SKU	variantId/SKU	attributes/active	sellable unit
Offer	offerId	price/eligibility/window	seller+variant+market
Cart line	lineId	quantity/selection	offer/variant snapshot
Quote	quoteId	version/expiry	priced cart + delivery options
Order line	orderLineId	ordered/cancelled/fulfilled/returned qty	immutable commercial snapshot
Reservation	reservationId	held/committed/released/expired	SKU+location+order/quote
Fulfillment	fulfillmentId	planned/packed/shipped/delivered	specific order lines/quantities

Catalog Contract: Product، Variant و Offer را قاطی نکنید

Product توضیح مفهومی کالا است؛ Variant ترکیب قابل انتخاب مانند اندازه/رنگ؛ SKU واحد عملیاتی؛ و Offer پیشنهاد فروش از Seller/Market با Price و Availability است. مدل واقعی محصول ممکن است متفاوت باشد، اما QA باید نام‌ها را به رفتار مشخص وصل کند.

Catalog Offer Contract
productId / variantId / sku: stable identities
offerId / sellerId / market: selling context
attributes:                   versioned selectable dimensions
title/media/content:          locale and source
price/currency:               canonical values and display rule
availability/promise:         state, quantity policy and freshness
eligibility:                  customer/region/channel constraints
effective window:             startsAt/endsAt/timezone
fulfillment methods:          ship/pickup/digital/... 
return policy reference:      versioned, not copied prose
feed/structured-data mapping: field-level lineage
updatedAt/version:            ordering and staleness control

• Variant combination ناموجود قابل انتخاب و Add-to-cart نباشد.
• تعویض Variant، تصویر، SKU، قیمت، موجودی و URL/State مرتبط را هم‌زمان به‌روز کند.
• Disabled/archived Offer در Cart قدیمی بی‌صدا قابل خرید نشود.
• Seller یا Location اشتباه در Checkout تغییر نکند.
• Effective window با timezone و cache invalidation آزموده شود.
• Content ترجمه‌شده Identity یا Attribute canonical را عوض نکند.
• Feed، PDP، structured data و Checkout به Version قابل پیگیری وصل باشند.

قیمت و موجودی را میان Surfaceها تطبیق دهید

قیمت یا Availability ممکن است در Search feed، Landing page، Structured Data، API، Cart و Checkout متفاوت باشد. این اختلاف همیشه bug نیست—Shipping، Tax، membership یا regional rule می‌تواند تفاوت موجه بسازد—اما علت و breakdown باید Contract داشته باشد.

مشخصات جاری Product Data در Google Merchant Center برای استفاده از آن سرویس، سازگاری price/currency و availability را میان product data، Landing page، structured data و Checkout می‌خواهد. این یک Requirement خاص Google/Merchant Center است، نه قانون عمومی Ecommerce و نه تضمین رتبه یا نمایش.

Surface	Price fields	Availability	Freshness/identity evidence
Feed	amount+currency+sale window	feed enum/value	feed run/item/version
Structured data	Offer price/currency	schema availability	rendered page/canonical
PDP	selected Variant/Offer display	promise text/action	variant/offer IDs
Cart	line price and change notice	soft validation	cart version
Quote/Checkout	authoritative breakdown	reservation eligibility	quote ID/version/expiry
Order	immutable accepted snapshot	ordered quantity/state	order line provenance

Search، Category و Facet را فقط با چند Query تست نکنید

Search باید lexical/semantic policy، typo، synonym، locale، SKU، attribute، ranking و unavailable handling مشخص داشته باشد. Category و Facet نیز AND/OR semantics، count، URL، pagination، canonical/noindex policy و reset/back navigation می‌خواهند. نتیجه «مرتبط» بدون Oracle و query intent قابل سنجش نیست.

• Exact SKU و Product title با Unicode/اعداد مختلف؛
• ی/ی، ک/ک، فاصله و نیم‌فاصله و جمع/املای مصوب؛
• Variant attribute و ترکیب Facetها؛
• Out-of-stock policy، preorder و hidden products؛
• Zero-result، spell suggestion و recovery path؛
• Pagination/infinite scroll بدون duplicate یا missing item؛
• Sort stability هنگام update موجودی/قیمت؛
• Authorization/market-specific catalog isolation؛
• Analytics event schema بدون duplicate impression/click.

راهنمای رسمی Google Search برای ساختار Ecommerce توضیح می‌دهد Productهایی که فقط از Search box قابل دسترسی‌اند ممکن است با Crawl navigation پیدا نشوند و استفاده از لینک‌های واقعی میان Category/Subcategory/Product اهمیت دارد. این توصیه را با sitemap، canonical، internal link و crawl test بیازمایید؛ نتیجه رتبه‌بندی را تضمین نکنید.

Cart Contract: سبد یک آرایه موقت نیست

Cart Contract
cartId / owner:        guest session or customer identity
version:               optimistic concurrency / change sequence
lineId:                stable line identity
variant/offer/seller:  selected sellable context
quantity:              min/max/step and current eligibility
price reference:       display estimate vs locked quote
promotion state:       entered/applied/rejected + reasons
fulfillment choice:    if known, versioned
market/currency:       explicit, not inferred silently
expiry:                cart and line policy
merge policy:          guest→member conflict resolution
reprice policy:        what changes and how user is informed
audit/events:          minimal and privacy-aware

Scenario	تزریق	Invariant
Double add	دو tap/retry هم‌زمان	quantity طبق intent، نه duplicate side effect
Guest merge	سبد مهمان و حساب line مشابه دارند	merge policy صریح؛ no silent loss/double
Stale offer	قیمت/موجودی تغییر می‌کند	revalidate/reprice و change disclosure
Variant removed	Offer غیرفعال می‌شود	Checkout block یا replacement choice؛ no substitution silent
Multi-tab	دو نسخه Cart تغییر می‌کنند	version conflict/merge deterministic
Quantity boundary	۰، منفی، بیش از limit، decimal	domain-specific validation server-side
Market switch	locale/currency/region تغییر می‌کند	eligible lines re-evaluated و notice

Quote را Snapshot قابل قبول و منقضی‌شونده ببینید

Cart ممکن است تخمینی و mutable باشد؛ Quote باید مجموعه‌ای مشخص از lineها، قیمت، تخفیف، هزینه ارسال، مالیات/عوارض مصوب، currency، promise، policy و expiry را به Checkout وصل کند. اگر هر input مهم تغییر کرد، Quote قبلی نباید بی‌صدا اجرا شود.

Quote Contract
quoteId / version / createdAt / expiresAt
customer/guest/market/currency context
lines: variant + seller + quantity + unit price
discounts: rule/version/allocation/reason
shipping: method/price/promise/source
tax/charges: approved rule/source/breakdown
total: canonical money contract
inventory policy: checked vs held vs reserved
address/input fingerprint
terms/policy references
acceptance action and authorization
revalidation triggers and changed-field disclosure

• Quote expired درست reject/reprice شود.
• همان Quote دوبار Order نسازد.
• تغییر Address یا shipping method Quote را version کند.
• Line حذف‌شده و total جدید پیش از تأیید آشکار باشند.
• Currency/market switch Quote قدیمی را invalidate کند.
• Server amount را از Client hidden fields نپذیرد.
• Order accepted snapshot دقیقاً به Quote پذیرفته‌شده trace شود.

Promotion و Coupon را Rule Engine تست کنید

«کد اعمال شد» کافی نیست. Eligibility، window، market، customer segment، usage limit، per-account/global limit، stacking، minimum spend، eligible lines، allocation، cancellation و refund behavior باید Contract داشته باشند. Conversion هدف Product است؛ QA صحت Rule و Evidence را می‌سنجد.

بعد	Case	خطر
زمان	قبل/در/بعد start-end و timezone	فعال‌ماندن یا شروع زودهنگام
مصرف	دو Checkout هم‌زمان آخرین quota	عبور از global/user limit
Stacking	ترتیب دو Promotion	total وابسته به order ناخواسته
Minimum	مرز قبل/بعد discount/shipping	base مبهم
Allocation	تخفیف روی چند line و residual	refund breakdown غلط
Eligibility	seller/variant/customer/market	اعمال به Offer نامجاز
Replay	Order retry یا Coupon reuse	مصرف دوباره یا quota leak
Cancellation	Order لغو می‌شود	quota restoration طبق policy

Inventory: On-hand با Available یکی نیست

موجودی می‌تواند On-hand، Reserved، Available-to-promise، Safety stock، Damaged، In-transit یا Backordered داشته باشد. فرمول و Source باید برای محصول مشخص شود. نمایش «موجود» بدون Location، freshness و promise ممکن است در Checkout فروبریزد.

Inventory Contract
sku / location / inventoryVersion
onHand:          physically/accounted quantity per source
reserved:        active holds not yet committed/released
safetyStock:     protected quantity per policy
available:       approved formula, not assumed universally
incoming:        quantity + confidence + expected time
promiseState:    in_stock/out_of_stock/preorder/backorder/... 
reservationId:  owner/order/quote/quantity/expiry
commit/release:  legal state transitions and idempotency
oversellPolicy:  prohibited or explicit controlled policy
freshness:       source timestamp/version and stale behavior
reconciliation: inventory source vs reservations/orders

Reservation و Oversell را با Concurrency تست کنید

دو Request می‌توانند هر دو Available=۱ بخوانند و هر دو Order بسازند. Test باید Schedule را کنترل کند: هر دو پس از Read متوقف، سپس هم‌زمان Reserve کنند. نتیجه طبق Policy ممکن است یک Winner و یک Failure/Backorder باشد؛ QA Policy را اختراع نمی‌کند.

Race	Schedule	Invariant
Last unit	دو reservation روی Available=۱	Oversell فقط اگر policy صریح اجازه دهد
Expiry vs commit	TTL هم‌زمان با Payment success	یک transition نهایی و compensating path
Cancel vs pack	لغو هم‌زمان با Fulfillment claim	state conflict بدون double release/ship
Quantity update	Cart از ۱ به ۲ هنگام stock change	reservation delta atomic
Location selection	دو warehouse candidate	یک allocation یا split صریح
Inventory event order	v2 out سپس v1 in	Current version عقب نرود
Import duplication	snapshot/delta دوباره	quantity دو بار اعمال نشود

Checkout را State Machine و Saga ببینید

Checkout چند side effect در سیستم‌های مختلف دارد. Atomic transaction واحد معمولاً همه Partnerها را پوشش نمی‌دهد؛ پس هر Step و compensation باید state، identity و retry Contract داشته باشد. ترتیب دقیق محصول می‌تواند متفاوت باشد.

Checkout Saga — illustrative
Quote accepted
  → inventory reserve
  → order create/pending
  → payment intent/authorization
  → order confirm
  → reservation commit
  → fulfillment request
  → notification

At each boundary:
- command/event ID and idempotency scope
- expected state/version
- side effect evidence
- timeout/unknown handling
- retry rule
- compensation owner/action
- reconciliation query
- user-visible message and next step

• Refresh و Back/Forward Order دوم نسازند.
• Double submit و mobile retry اثر یکتا داشته باشند.
• Payment unknown با Failed قطعی یکی نشود.
• Reservation failure پس از Payment به compensation/operations روشن برود.
• Order create success و response loss با lookup/retry بازیابی شود.
• Notification failure Order را ناموجود یا rollback خام نکند مگر Contract چنین باشد.
• هر State برای Customer support قابل توضیح و traceable باشد.

Address، Delivery Option و Promise را Contract کنید

Address validation نباید بر حدس عمومی یا API خارجی تنها تکیه کند. فیلد، format، normalization، serviceability، privacy و fallback را برای بازار هدف تعیین کنید. Delivery promise نیز quote است، نه ضمانت؛ منبع، cut-off، calendar، capacity و exception باید ثبت شوند.

ناحیه	Scenario	Oracle
Unicode	فارسی/عربی/لاتین، نیم‌فاصله، خط جدید	پذیرش/نمایش/برچسب طبق carrier contract
Normalization	پلاک/واحد/کدپستی تغییر format	معنا حفظ و تغییر به کاربر نشان داده شود
Serviceability	منطقه پشتیبانی‌نشده	option نامعتبر پیشنهاد نشود
Cut-off	قبل/بعد زمان روز کاری	promise/date مطابق calendar version
Capacity	دو نفر آخرین slot	reservation concurrency کنترل شود
Address change	پس از Quote یا Order	reprice/revalidate و authorization
Provider down	rate API timeout	fallback/hold روشن؛ no invented price

Order Contract: Snapshot تجاری را حفظ کنید

Order نباید هنگام مشاهده آینده از Catalog زنده title، price یا seller را دوباره بخواند و تاریخ را تغییر دهد. Order line باید Snapshot پذیرفته‌شده و referenceهای provenance را نگه دارد؛ اصلاحات با Event/Version جدید انجام شوند.

Order Contract
orderId / orderVersion / customer-or-guest reference
market / locale / canonical currency
order lines: stable IDs + product/variant/offer/seller snapshots
quantity states: ordered/cancelled/allocated/fulfilled/returned
accepted quote: quoteId/version and amount breakdown
inventory: reservation/allocation references
payment: intent/auth/capture references and states
fulfillment groups: line quantities + location/method
policy snapshots: return/cancellation/terms references
timestamps: created/effective/confirmed with timezone context
events/audit: immutable business history
manual changes: role/reason/approval/evidence

Payment را به Order وصل کنید، اما یکی نکنید

Payment Captured ممکن است با Order Cancelled یا Fulfillment blocked هم‌زمان شود. Order و Payment state باید جدا و با rules/reconciliation مرتبط باشند. Success callback یا Return URL منبع قطعی Order fulfillment نیست؛ server-side evidence و idempotent processing لازم است.

حالت ترکیبی	مسئله	Expected path
Order pending + payment authorized	reservation/confirm در حال انجام	bounded unknown، retry/reconcile
Order confirmed + payment unknown	response گم شده	provider lookup؛ no blind repay
Payment captured + inventory failed	compensation لازم	hold/refund/manual path طبق policy
Duplicate capture event	Fulfillment job دوم	event dedupe و unique business effect
Payment failed + late success	state ordering	version/source rules و reconcile
Refund complete + return missing	policy یا fraud/ops exposure	cross-domain exception workflow

قواعد Amount، Currency، Idempotency، Ledger و Settlement در راهنمای مالی لینک‌شده بررسی می‌شوند. Checkout QA نباید اطلاعات کارت، OTP یا credential واقعی در Fixture یا Log نگه دارد.

Fulfillment را از یک Status ساده فراتر ببرید

یک Order می‌تواند به چند Seller، Warehouse، Package یا Shipment تقسیم شود. Fulfillment group باید line quantity دقیق، source Location، method، promise و lifecycle داشته باشد. ساخت Label یا Tracking ID به‌تنهایی Shipment واقعی یا Delivery را ثابت نمی‌کند.

• Allocation مجموع quantity سفارش را بدون overlap/gap پوشش دهد.
• Split و partial fulfillment State line و Order summary را درست به‌روز کنند.
• Duplicate payment/order event Job یا Label دوم نسازد.
• Pack short/damaged item به exception و inventory adjustment وصل شود.
• Carrier timeout-after-create با idempotent lookup/retry مدیریت شود.
• Tracking eventهای out-of-order Current status را عقب نبرند.
• Delivery event بدون proof/contract لازم خودکار پایان همه Workflowها نشود.
• Notification به package/shipment درست و locale مناسب اشاره کند.

Cancellation را در هر Boundary تست کنید

لغو قبل از Payment، پس از Authorization، پس از Capture، پس از Allocation یا هنگام Pack اثر یکسانی ندارد. Eligibility، actor، deadline، inventory release، payment action، coupon quota، seller/carrier cancellation و customer message را per-state تعریف کنید.

Boundary	Race	Invariant
Before confirm	cancel vs submit	یک نتیجه نهایی و no orphan hold
Reserved	cancel vs reservation expiry	quantity یک بار آزاد شود
Payment pending	cancel vs late success	reconcile/compensate طبق policy
Allocated	cancel vs warehouse claim	line quantity conflict کنترل شود
Packed/Shipped	cancel درخواست می‌شود	reject/intercept/return path صریح
Partial order	برخی lineها لغو	totals/discount/shipping/refund reallocation درست

Return، Refund و Restock را سه Workflow جدا ببینید

Return درخواست/حرکت کالا است؛ Refund اثر مالی؛ Restock تصمیم موجودی/کیفیت. ممکن است Refund بدون Return یا Return بدون Restock طبق Policy رخ دهد. سیستم نباید آن‌ها را با یک Boolean ببندد.

Return Contract
returnId / orderId / orderLineId / quantity
policyVersion / eligibility / window / reason
requested → approved/rejected → in_transit → received → inspected → resolved
resolution: refund/replacement/store-credit/repair/... per product
refund reference and amount breakdown
restock disposition: sellable/damaged/quarantine/no-restock
shipping/fee responsibility per approved policy
duplicate request and concurrent quantity rules
evidence: item/condition/actor/timestamps with privacy controls

• مجموع return quantity از fulfilled quantity مجاز عبور نکند.
• دو Return هم‌زمان برای آخرین واحد race را کنترل کنند.
• Refund retry اثر مالی دوم نسازد.
• Replacement Order با Return و Inventory references trace شود.
• Restock فقط پس از disposition مناسب مقدار را تغییر دهد.
• Partial return، discount allocation و shipping policy نسخه‌دار باشد.
• Policy تغییرکرده Order تاریخی را بی‌صدا بازتفسیر نکند.

Marketplace: Seller و Line ownership را حفظ کنید

در Marketplace، Cart واحد می‌تواند چند Seller و چند Offer داشته باشد. Order split، commission، fulfillment، cancellation، return، dispute و payout به مالک line وابسته‌اند. تعویض Seller هنگام reprice یا fallback نباید بدون consent/Contract رخ دهد.

Scenario	خطر	Evidence
Offer winner changes	Seller/price/promise silent substitution	quote fingerprint و user confirmation
Multi-seller cart	shipping/discount allocation غلط	per-line/seller breakdown
Seller suspension	Cart/Order قدیمی	eligibility transition and ops path
Partial cancellation	seller دیگر تحت تأثیر	isolated state/totals
Return routing	کالا به مقصد اشتباه	seller/fulfillment ownership
Payout readiness	delivery/refund/dispute lag	financial reconciliation reference

کالای دیجیتال و Subscription Contract متفاوت دارند

کالای دیجیتال Inventory فیزیکی ندارد، اما Entitlement، download limit، region/device، license، version و revoke دارد. Subscription نیز Term، renewal، trial، proration، grace، failed charge و cancellation effective date دارد. این صفحه فقط مرزها را مشخص می‌کند؛ Billing policy باید جدا تصویب شود.

نوع	Invariant نمونه	Failure case
Digital entitlement	Order/payment state مجاز ↔ access یکتا	duplicate callback دو license می‌سازد
Download	signed link scope/expiry/download policy	URL share یا replay
Trial	start/end/eligibility/version روشن	trial stacking یا early charge
Renewal	one billing event per term	job retry charge دوباره
Plan change	effective date/proration approved	double entitlement یا gap
Cancellation	access end و future charge طبق policy	cancel UI ولی renewal فعال

Notification شاهد Delivery نیست

ارسال Email/SMS/Push پایان Order نیست و Delivery پیام نیز خواندن یا فهمیدن را ثابت نمی‌کند. Notification باید از State معتبر ساخته، با Event ID deduplicate، شامل حداقل داده و لینک امن، و با retry/expiry/locale درست باشد.

• Order confirmation فقط پس از State تعریف‌شده ارسال شود.
• Duplicate event پیام تکراری ناموجه نسازد.
• Late event پیام قدیمی پس از State جدید نفرستد.
• Template version با locale و RTL صحیح باشد.
• PII، token و جزئیات حساس بیش از نیاز نمایش داده نشود.
• Unsubscribe/transactional classification طبق تصمیم حقوقی محصول باشد.
• Failure notification در Queue قابل مشاهده و replay امن باشد.
• Support timeline بین notification و Order state reconcile شود.

Usability، Accessibility و Conversion را جدا گزارش کنید

Functional pass می‌گوید Button عمل کرد؛ Usability study می‌سنجد کاربر هدف Task را چگونه انجام داد؛ Accessibility بررسی می‌کند افراد با نیازها و فناوری‌های کمکی می‌توانند perceivable/operable/understandable/robust تعامل کنند؛ Conversion metric رفتار Aggregated Production است. هیچ‌کدام به‌تنهایی دیگری را ثابت نمی‌کند.

برای طراحی مطالعه از راهنمای تست کاربردپذیری و برای WCAG ۲.۲، Keyboard، Focus، Name/Role/Value، Error و Status message از راهنمای تست دسترس‌پذیری استفاده کنید. صفحه رسمی Understanding WCAG ۲.۲ از W3C منبع تفسیری معیارهاست؛ Accessibility conformance هم موفقیت تجاری را تضمین نمی‌کند.

Evidence	می‌گوید	نمی‌گوید
Functional assertion	State/DOM/API طبق Oracle بود	کاربر می‌فهمد یا فروش بالا می‌رود
Task success	شرکت‌کننده Task تعریف‌شده را انجام داد	همه کاربران یا همه Contextها موفق‌اند
Accessibility test	معیار/مسیر مشخص evidence دارد	تمام معلولیت‌ها یا تجربه کامل پوشش دارد
A/B experiment	در طراحی/جمعیت/زمان مشخص تفاوت مشاهده شد	causality خارج طرح یا کیفیت فنی کامل
Conversion rate	نسبت تعریف‌شده در داده مشاهده شد	چرا تغییر کرد یا کاربر راضی است

Compatibility را بر Risk واقعی بنا کنید

فهرست Chrome/Firefox/Safari/Edge برای پوشش کافی نیست. Browser engine/version، OS، viewport، input، network، storage/cookie policy، WebView، payment redirect، autofill، locale، assistive technology و traffic/support data ماتریس را می‌سازند.

• Same-site/third-party cookie policy و return from provider؛
• Back-forward cache و resubmit Checkout؛
• Mobile WebView و deep link return؛
• Autofill address و validation interaction؛
• Low-memory reload و Cart persistence؛
• Offline/online transition و duplicate command؛
• Touch/keyboard/zoom/reflow؛
• RTL mixed-content، تاریخ/عدد و چاپ Order؛
• Browser extension/content blocker impact در analytics versus core flow.

راهنمای طراحی Browser و Device Matrix روش انتخاب ترکیبات و گزارش Unsupported/Unknown را توضیح می‌دهد. «روی موبایل تست شد» بدون Device/OS/Browser/build evidence کافی نیست.

فارسی، RTL، ریال و تومان را End-to-End تست کنید

Localization فقط ترجمه Label نیست. Catalog، Search، Variant، Price، Address، Checkout، Order، Invoice، Notification، Tracking و Return باید در فارسی بررسی شوند. Currency canonical را از display unit جدا نگه دارید؛ «تومان» label و conversion rule صریح می‌خواهد.

• ی/ی، ک/ک، ارقام ۰۱۲/۰۱۲/۰۱۲ و normalization جستجو؛
• نیم‌فاصله، wrapping، font fallback و truncation نام Product؛
• RTL Grid، breadcrumb، filter drawer، carousel و mixed LTR SKU؛
• Amount/currency order، separator و ریال/تومان؛
• آدرس چندخطی، پلاک/واحد و label چاپ؛
• UTC/Asia-Tehran و تاریخ شمسی فقط به‌عنوان نمایش قراردادی؛
• Dynamic variables در Email/SMS و bidi isolation؛
• Alt، accessible name و validation message فارسی؛
• Fallback locale و missing translation بدون نمایش key خام.

چک‌لیست عمیق‌تر در راهنمای تست i18n و L10n فارسی/RTL آمده است. نمایش درست رقم فارسی صحت Money Contract یا Order total را ثابت نمی‌کند.

Security و Privacy را به Journey وصل کنید

Cart price tampering، IDOR Order، coupon abuse، inventory hoarding، bot checkout، credential stuffing، seller isolation، admin adjustment و return fraud نمونه‌هایی از Business/Access risk هستند. Client validation یا پنهان‌کردن Button کنترل server-side نیست.

Boundary	Threat/Privacy question	Control evidence
Catalog/price	Client amount یا seller قابل دستکاری است؟	server reprice/authorization
Cart/checkout	Cart دیگر یا coupon quota قابل حدس/مصرف است؟	object/action authorization
Order	کاربر به Order/Address دیگری دسترسی دارد؟	tenant/customer scope tests
Inventory	Bot با reservation موجودی را قفل می‌کند؟	limits/expiry/detection/release
Admin/support	Adjustment بدون role/reason/approval؟	least privilege/audit
Analytics/session replay	PII/secret/payment fields ضبط می‌شوند؟	data minimization/masking/access
Notification	Link/token یا جزئیات حساس نشت می‌کند؟	scope/expiry/minimal content

برای Threat modeling و روش‌های AppSec از راهنمای تست امنیت نرم‌افزار استفاده کنید. Heatmap، session recording و analytics نیز data flow، consent/notice، masking، retention و vendor review می‌خواهند؛ ابزار UX خودکار مجوز جمع‌آوری داده نیست.

Performance را با Campaign و Correctness همراه کنید

ادعای عمومی «هر یک ثانیه X درصد Conversion کم می‌کند» بدون Context و منبع معتبر برای سایت شما Oracle نیست. Performance target را از Journey، device/network، SLO، ظرفیت، داده و Risk بگیرید. پس از Load فقط latency را نبینید؛ Order، Reservation و Fulfillment invariants را هم بررسی کنید.

Workload	Metric	Correctness companion
Browse/search burst	p50/p95/p99، cache hit، error	price/availability version/freshness
Flash sale add-to-cart	throughput/queue/lock	quantity/offer eligibility
Last-unit checkout	conflict/retry latency	no unapproved oversell
Payment callback burst	consumer lag	unique Order/Fulfillment effect
Campaign promotion	rule latency/saturation	quota/stack/allocation invariants
Carrier/provider slow	timeout/retry/backlog	bounded unknown/no duplicate
Recovery catch-up	oldest age/time to drain	reconciliation after replay

ساخت مدل بار و معیار پذیرش در راهنمای برنامه تست عملکرد پوشش داده شده است. Flash sale فقط Stress test نیست؛ inventory fairness، queue policy، abuse controls و customer messaging نیز تصمیم محصول/عملیات‌اند.

Fault Injection را در Boundaryهای Order اجرا کنید

Failureهای ارزشمند بین دو اثر رخ می‌دهند: Reserve انجام و Response گم؛ Payment ثبت و Order confirm crash؛ Label در Carrier ساخته و local record ذخیره نشده. در محیط مجاز response، ack، network، clock یا process را دقیقاً در Boundary قطع کنید.

Fault point	Unknown	Recovery evidence
بعد Reserve/قبل response	Cart نمی‌داند hold ساخته شد	idempotent lookup/retry/expiry
بعد Order create	Client دوباره submit می‌کند	same order result
بعد Payment success	Order pending است	provider→order reconciliation
بعد Fulfillment create	Job/label local unknown	external reference lookup
قبل Event ack	delivery دوباره	dedupe/no second side effect
Catalog delta missing	price/stock stale	version lag alert/full reconciliation
Notification down	Customer informed نیست	retry/escalation بدون Order duplication

Test Data را قابل‌خرید اما غیرواقعی بسازید

Fixture باید Catalog و Order relation واقعی‌نما داشته باشد، اما به Customer، Seller، Warehouse، Carrier، Card، Phone یا Address واقعی وصل نباشد. Namespace ساختگی، Egress denial و Stubهای محلی مانع ارسال اشتباه می‌شوند.

Synthetic Commerce Fixture Manifest
generatorVersion / seed / checksum
products / variants / SKUs / offers / sellers
prices / currencies / promotion rule versions
locations / inventory / reservation clocks
guest/member synthetic identities
addresses marked non-routable and fictional
quotes / orders / payments / fulfillments / returns
partner stubs and deterministic fault scripts
expected state transitions and invariants
network deny/allow list
retention / cleanup / access owner

• Productها با `SYN-` و تصویر/متن ساختگی مشخص باشند.
• Address و Phone هیچ فرد یا مقصد واقعی را تقلید نکنند.
• هیچ PAN، CVV2، OTP، token، credential یا API key واقعی وجود نداشته باشد.
• Email/SMS/Carrier sink محلی باشد و خروجی واقعی نداشته باشد.
• SKU/Variant/Offer collision و edgeهای Unicode عمداً ساخته شوند.
• Time با clock قابل کنترل و event ordering deterministic باشد.
• Fixture expected Order/Inventory/Fulfillment graph داشته باشد.
• پس از Run، orphan reservation/job/data cleanup و verify-absent شود.

Migration و Reindex را با Count تمام نکنید

تعویض Commerce platform، Search index، Catalog model یا Order service می‌تواند Identity و History را بشکند. Count برابر با Variant/Offer mapping، price version، reserved quantity یا Order line lineage درست نیست.

ناحیه	کنترل	Failure نمونه
Catalog	product→variant→offer graph	دو Variant merge شده‌اند
URL/SEO	canonical/redirect/internal link/feed	Product orphan یا duplicate URL
Price	current+future rule/version	sale window timezone جابه‌جا
Inventory	on-hand/reserved/available per location	active reservations جا مانده‌اند
Cart	offer eligibility/reprice policy	line قدیمی silent substitute
Order	immutable snapshots/history/quantities	catalog live history را عوض می‌کند
Search	population/version/query suite	index success ولی products missing
Cutover	snapshot+delta+dual-write/reconcile	gap یا duplicate order

Production Monitoring را به Journey و Invariant وصل کنید

Conversion، Revenue یا Error rate تنها کافی نیستند. Conversion کاهش می‌یابد اما علت را نمی‌گوید؛ Revenue بالا می‌رود اما duplicate charge را پنهان می‌کند؛ Error پایین است اما Queue عقب افتاده. Funnel را با technical/business state و reconciliation همراه کنید.

Signal	Counter-signal	Slice	Owner action
PDP views	offer/stock stale errors	market/variant/channel	catalog/feed inspect
Add-to-cart	reprice/invalid offer rate	seller/promotion	contract drift review
Checkout starts	quote expiry/address/payment unknown	step/device/provider	journey trace
Orders created	unique quote/order ratio	channel/retry class	idempotency review
Reservations	expired/orphan/negative/oversell	SKU/location	inventory reconcile
Payment success	order confirm/fulfillment lag	provider/state	cross-system reconcile
Fulfillment jobs	unique order-line effect	warehouse/seller	dedupe/hold
Returns	refund/restock mismatch aging	reason/policy	exception workflow

Metric و Event analytics باید schema/version، identity، missing/duplicate rate و consent/privacy controls داشته باشند. Session recording یا heatmap نباید password، address، payment field یا پیام خصوصی را ضبط کند.

Release Identity و Evidence Pack را کامل کنید

Commerce Release Identity
code/image digest:          ___
database schema/migrations: ___
catalog/search index build: ___
price/promotion rules:      ___
inventory/reservation policy:___
quote/order state versions: ___
payment/fulfillment mappings:___
shipping/calendar/cut-off:  ___
return/refund policy:       ___
feature flags/routing:      ___
locale/templates/content:   ___
synthetic fixture/seed:     ___
evidence pack/checksum:     ___

Config، Promotion، Catalog feed، Search synonym، inventory safety stock، shipping calendar و Return policy می‌توانند بدون Deploy کد Journey را تغییر دهند. Impact analysis باید Evidence مرتبط را stale علامت بزند.

Release Gate را با Critical Journey بسازید

Ecommerce Release Memo
Scope/business model/channels:      ___
Release identity:                  ___
Critical journeys and invariants:  ___
Catalog/price/inventory evidence:  ___
Checkout/order/payment evidence:   ___
Fulfillment/return evidence:       ___
Security/privacy/a11y/performance: ___
Failure/recovery/reconciliation:   ___
Open defects and customer exposure:___
Blocked/inconclusive/stale evidence:___
Rollback/feature flags/runbooks:   ___
Production monitors and owners:   ___
Residual risk and limitations:    ___
Recommendation: Go / Conditional / Hold
Authorized decision and expiry:   ___

Gate	نمونه شرط	اشتباه رایج
Catalog	critical SKUs/Offers valid and fresh	فقط PDP screenshot
Price	Quote/Order breakdown with version	فقط total UI
Inventory	last-unit concurrency و orphan scan	single-user stock test
Order	double submit/timeout recovery	Happy Path only
Fulfillment	unique line effects and split/partial	job count only
Unknown	blocked/inconclusive exposure explicit	skipped as neutral
Operations	rollback/reconcile/runbooks rehearsed	dashboard exists

آزمایش بازتولیدپذیر: Last Unit و Callback تکراری

Fixture `fictional-ecommerce-order-v1` کاملاً ساختگی و آفلاین است. یک SKU خیالی `SKU-SYN-A` فقط یک واحد Available دارد. دو Cart هم‌زمان هر کدام Quantity=۱ می‌خواهند. سپس یک Payment capture Event برای Order برنده دو بار Deliver می‌شود و Availability v2=`out_of_stock` پیش از Event قدیمی v1=`in_stock` می‌رسد.

Inputs
initialAvailable = 1
checkouts = CART-SYN-A + CART-SYN-B
payment deliveries = PAY-CAP-SYN-A twice
availability events = v2 out_of_stock, then v1 in_stock

Naive model
- both checkouts read the same snapshot
- every payment delivery creates a fulfillment job
- last arrival becomes displayed availability

Contract-aware model
- atomic reservation consumes available quantity
- eventId has one business effect
- only greater availability version becomes current

روش	Order result	Available/Oversell	Fulfillment jobs	Displayed availability
Naive snapshot/arrival-wins	۲ confirmed	−۱ / Oversell=۱	۲	in_stock از v1 قدیمی
Contract-aware	۱ reserved، ۱ inventory_unavailable	۰ / Oversell=۰	۱؛ duplicate ignored=۱	out_of_stock v2؛ stale ignored=۱

{
  "fixture": "fictional-ecommerce-order-v1",
  "naive": {
    "confirmedOrders": 2,
    "resultingAvailable": -1,
    "oversoldUnits": 1,
    "fulfillmentJobs": 2,
    "displayedAvailability": "in_stock"
  },
  "contractAware": {
    "reservedOrders": 1,
    "inventoryUnavailableOrders": 1,
    "resultingAvailable": 0,
    "oversoldUnits": 0,
    "fulfillmentJobs": 1,
    "duplicatePaymentEventsIgnored": 1,
    "displayedAvailability": "out_of_stock",
    "availabilityVersion": 2,
    "staleAvailabilityEventsIgnored": 1
  }
}

این خروجی فقط مکانیک یک Simulation تک‌پردازه و عمدی را نشان می‌دهد. Database isolation، distributed lock، Queue، Payment، Warehouse، Customer، UI، شبکه، امنیت، عدالت تخصیص یا Policy واقعی را آزمایش نمی‌کند. اعداد فروش، Conversion، Traffic، احتمال Oversell، Capacity یا Benchmark نیستند. مدل قراردادی نیز «راه‌حل عمومی» نیست؛ فقط Invariantهای Fixture را حفظ کرده است.

درس محدود: تست Checkout باید simultaneous reservation، duplicate Event و out-of-order version را کنار Happy Path اجرا کند و اثر را در Order، Inventory و Fulfillment با هم بسنجد.

سناریوی بومی: فروشگاه فارسی کاملاً مصنوعی

یک فروشگاه آزمایشی داخلی را با Product، Variant، Seller، Order و Addressهای `SYN-*` بسازید. Currency canonical در Fixture برابر IRR است و UI می‌تواند تومان را فقط با label و conversion مصوب نشان دهد. هیچ درگاه، PSP، بانک، Carrier، پیامک، Email، Warehouse، Seller، Customer یا نشانی واقعی متصل نیست و درباره قوانین یا شبکه تجارت ایران ادعایی ندارد.

ریسک	تزریق ساختگی	Invariant	Evidence
Product identity	دو Variant با عنوان مشابه	SKU/Offer صحیح در Cart/Order	ID graph
فارسی/RTL	ی/ی، ک/ک، سه رقم، mixed SKU	Search/display/selection consistent	API/UI/print
ریال/تومان	IRR API و تومان UI	Quote/Order canonical بدون ضریب اشتباه	breakdown trace
Last unit	دو Checkout هم‌زمان	Oversell طبق Policy	reservation schedule
Callback duplicate	Capture event دوبار	یک Fulfillment effect	dedupe/job trace
Time	UTC نزدیک cut-off، تهران/شمسی نمایش	Rule بر instant/business date مصوب	quote/promotion timeline
Failure	Stub response بعد Commit حذف	same Order lookup/retry	idempotency/reconcile
No egress	تلاش Notification/Carrier/Payment	local sink یا fail closed	network policy log

نقش‌ها و Decision Rights

نقش	مسئولیت نمونه	نباید به‌تنهایی ادعا کند
Commerce Product	Journey، State، Promise، Policy	صحت فنی یا قانونی بدون Evidence
Merchandising/Pricing	Catalog/Offer/Promotion rules	Account/Payment correctness
Inventory/Fulfillment Ops	stock/reservation/allocation/shipping	تغییر silent customer contract
Engineering	identity، concurrency، events، observability	پذیرش مستقل residual risk
QA/Test	risk scenarios، execution، evidence/limits	تضمین Conversion/فروش/انطباق
UX/Research/Accessibility	participant/task/a11y evidence	منطق Order/Inventory کامل
Security/Privacy/Legal	threat/data/applicability requirements	عملکرد Journey بدون Test
Operations/Risk owner	runbook، release و risk acceptance	پنهان‌کردن Unknown یا override بدون expiry

برنامه ۳۰روزه Pilot

هفته	خروجی	فعالیت	معیار پایان
۱: Context	Commerce context و entity map	یک SKU/Offer و Journey محدود، owners/sources	Success و source of truth روشن‌اند
۲: Contracts	Cart/Quote/Inventory/Order contracts	state، version، idempotency، policies	critical invariants approved
۳: Evidence	Synthetic deterministic suite	last unit، duplicate، timeout، stale، partial	Failureها reproducible و traceable‌اند
۴: Operations	monitor/reconcile/release memo	fault rehearsal، unknown review، runbooks	decision/owner/expiry ثبت شده‌اند

• با یک Variant، یک Offer و یک Location شروع کنید.
• Entity IDs و Source of Truth را پیش از UI tests رسم کنید.
• Quote و Order snapshot را به Price/Policy version وصل کنید.
• Last-unit race، double submit و duplicate callback را اجباری کنید.
• یک partial fulfillment و یک partial return اجرا کنید.
• پس از Failure، Order/Inventory/Payment/Fulfillment را reconcile کنید.
• در Retrospective بپرسید چه Unknownی تصمیم Release را تغییر داد.

ضدالگوهای رایج تست Ecommerce

ضدالگو	مسئله	اصلاح
تست تضمین فروش/Conversion	علت و بازار را ساده می‌کند	رفتار محدود + experiment/analytics جدا
PDP opens = buyable	Offer/stock/eligibility گم است	Offer contract
Product=SKU=Offer	Variant/Seller mismatch	entity identity map
Price UI only	Feed/quote/order mismatch	surface reconciliation
Cart total mutable silent	customer accepts unknown quote	version/reprice disclosure
Stock check then decrement	last-unit race	atomic reservation test
Payment callback = fulfillment	duplicate/out-of-order effects	dedupe/state/reconcile
Success page = complete order	unknown downstream state	saga evidence
One Order status	line/payment/fulfillment differences	separate state machines
Return=Refund=Restock	policy/quantity errors	linked workflows
Average latency + 7% claim	Context/causality ندارد	site-specific workload/evidence
Mobile emulator only	browser/device/input gaps	risk-based matrix
Heatmap without privacy	PII/secret capture	data-flow/consent/masking
Production orders in test	real-world side effects	synthetic namespace/no egress
Load test without invariants	سریع اما Oversold/duplicate	post-load reconciliation
Blocked test hidden	Unknown حذف می‌شود	exposure in release gate

چک‌لیست نهایی تست فروشگاه اینترنتی

• Business model، channel، market، customer mode و excluded journeys روشن‌اند.
• Product، Variant، SKU، Offer، Seller و Location شناسه مستقل دارند.
• Price/availability میان Feed، Structured Data، PDP، Cart، Quote و Order trace می‌شوند.
• Category/Search/Facet، Unicode، pagination و crawl navigation آزموده شده‌اند.
• Cart line identity، version، guest merge، expiry و reprice policy دارد.
• Quote amount/currency/breakdown/policy/expiry و acceptance snapshot دارد.
• Promotion eligibility، stacking، quota، time و allocation version شده‌اند.
• Inventory on-hand/reserved/available/safety/freshness semantics روشن است.
• Last-unit، reservation expiry/commit و stale availability race اجرا شده‌اند.
• Checkout Saga برای هر boundary idempotency، unknown و compensation دارد.
• Address، delivery option، slot/capacity و promise طبق بازار آزموده‌اند.
• Order line snapshot از Catalog زنده مستقل و history immutable است.
• Payment و Order state جدا و با evidence/reconciliation پیوند دارند.
• Fulfillment split/partial، duplicate job و tracking order بررسی شده‌اند.
• Cancellation در boundaryهای Reserve/Pay/Allocate/Pack/Ship آزموده شده است.
• Return، Refund و Restock workflow/quantity مستقل و linked دارند.
• Marketplace Seller/line ownership و multi-seller totals حفظ می‌شوند.
• Digital entitlement یا Subscription فقط اگر در Scope است Contract دارد.
• Notification duplicate/stale/locale/privacy و retry behavior آزموده شده است.
• Usability، Accessibility، Conversion و Functional evidence جدا گزارش می‌شوند.
• Browser/device/WebView/cookie/back/low-memory matrix مبتنی بر Risk است.
• فارسی/RTL، سه نوع رقم، ریال/تومان، آدرس و زمان End-to-End آزموده‌اند.
• Security/Privacy شامل object/action authorization و analytics data flow است.
• Load/Failure tests با Order/Inventory/Fulfillment invariants همراه‌اند.
• Fixtureها synthetic، seeded، no-egress و قابل cleanup هستند.
• Migration علاوه بر Count، graph، lineage، history و cutover را می‌سنجد.
• Monitoring funnel را با unique effects، lag، mismatch و aging همراه می‌کند.
• Release identity شامل Config/Rule/Index/Policy/Template و Code است.
• Blocked/Inconclusive/Stale به‌عنوان Unknown در Release Memo می‌آیند.

سؤالات متداول تست فروشگاه اینترنتی

تست تجارت الکترونیک دقیقاً چیست؟

طراحی و تولید Evidence برای Journey و سامانه‌های Commerce است: Catalog، Search، Offer، Cart، Quote، Checkout، Order، Inventory، Payment boundary، Fulfillment و Return، همراه با Quality characteristicهای مرتبط. نتیجه تست به Build، Context، داده و Oracle محدود است و فروش یا تجربه بی‌نقص را تضمین نمی‌کند.

مهم‌ترین سناریوی Checkout برای شروع چیست؟

یک Last-unit scenario با دو Checkout هم‌زمان، double submit و timeout-after-commit بسیار آموزنده است. بررسی کنید فقط نتیجه مجاز Inventory ساخته شود، Order یکتا بماند، Payment unknown قابل بازیابی باشد و Fulfillment job تکراری ایجاد نشود. Policy Oversell و compensation را Product/Ops تعیین می‌کنند.

آیا موفقیت پرداخت یعنی سفارش کامل شده است؟

خیر. Payment، Order، Reservation و Fulfillment Stateهای جدا دارند. حتی Capture موفق می‌تواند کنار inventory failure یا Order pending باشد. Source evidence، idempotency، reconciliation و compensation تعیین می‌کنند سیستم چگونه به وضعیت قابل توضیح می‌رسد.

چگونه Oversell را تست کنیم؟

Available را به مقدار مرزی برسانید، دو یا چند Reservation را با Barrier هم‌زمان کنید و State/quantity نهایی را با Contract مقایسه کنید. سپس expiry-versus-commit، cancel-versus-pack، duplicate inventory event و recovery را اجرا و Order/Reservation/Inventory را reconcile کنید.

آیا تست کامل فروشگاه باعث افزایش نرخ تبدیل می‌شود؟

تست می‌تواند Defect و مانع را آشکار و uncertainty را کم کند، اما Conversion به قیمت، محصول، بازار، ترافیک، پیام، فصل، رقابت و عوامل دیگر وابسته است. اثر تغییر را با Experiment و Analytics معتبر بسنجید و آن را با Functional، Usability و Accessibility evidence یکی نگیرید.

جمع‌بندی: Journey را به زنجیره Contract و Evidence تبدیل کنید

تست فروشگاه اینترنتی با کلیک‌کردن از Home تا Success تمام نمی‌شود. Catalog identity و Offer قابل خرید، Cart/Quote نسخه‌دار، Reservation اتمیک، Checkout Saga قابل بازیابی، Order snapshot، Payment boundary، Fulfillment یکتا و Return/Refund/Restock جدا، ستون‌های اصلی‌اند. Qualityهای امنیت، کاربردپذیری، دسترس‌پذیری، سازگاری، بومی‌سازی و Performance باید به همین Journey وصل شوند.

به‌جای «سایت کار می‌کند»، بپرسید: کدام Variant و Offer با چه Price/Availability پذیرفته شد؟ آخرین واحد را چه کسی Reserve کرد؟ هر Callback چند اثر ساخت؟ Order line چگونه Fulfill و Return شد؟ کدام اختلاف هنوز Unknown است و چه کسی ریسک آن را می‌پذیرد؟