--- title: Test Scenario Catalog tags: [testing, scenarios, qa, e2e] created: 2026-06-06 --- # Test Scenario Catalog This catalog lists the designed test flows. Each scenario should eventually have an automation owner, a smoke command, and a UAT checklist. ## Priority Model | Priority | Meaning | |---|---| | P0 | Blocks release or payment trust if failing. | | P1 | Core user experience or operational reliability. | | P2 | Important edge case with workaround. | | P3 | Nice-to-have or exploratory. | ## Scenario Matrix | ID | Scenario | Priority | Current status | Procedure | |---|---|---:|---|---| | ESCROW-E2E-001 | Buyer creates request, multiple sellers bid, buyer accepts, pays, seller delivers, buyer confirms | P0 | Live tested on dev, two rounds | [[Escrow Marketplace E2E Procedure]] | | PAY-SCAN-001 | BSC Testnet tUSDT direct-balance scanner confirms funded wallet transfer | P0 | Live tested on dev | [[Scanner BSC Testnet Payment Procedure]] | | PAY-SCAN-002 | Scanner/backend/frontend token registry consistency for chain 97 | P0 | Smoke covered | [[Smoke and Regression Procedure]] | | PAY-SCAN-003 | Wrong token contract does not confirm payment | P0 | Designed, needs automated negative test | [[Scanner BSC Testnet Payment Procedure#Negative scenarios]] | | PAY-SCAN-004 | Underpayment does not confirm payment | P0 | Designed, needs automated negative test | [[Scanner BSC Testnet Payment Procedure#Negative scenarios]] | | PAY-SCAN-005 | Wrong destination does not confirm payment | P0 | Designed, needs automated negative test | [[Scanner BSC Testnet Payment Procedure#Negative scenarios]] | | DELIVERY-001 | Seller delivery advances request to `delivery` | P0 | Live tested on dev | [[Escrow Marketplace E2E Procedure]] | | DELIVERY-002 | Buyer delivery confirmation advances request to `delivered` | P0 | Live tested after `2.8.117` id fix | [[Escrow Marketplace E2E Procedure]] | | DELIVERY-003 | Non-buyer cannot confirm delivery | P0 | Designed, should be regression test | [[Testing Expansion Backlog]] | | RELEASE-001 | Physical product enters grace period before release | P0 | Product policy not implemented | [[Testing Expansion Backlog]] | | RELEASE-002 | Gift card/digital product releases immediately after proof/confirmation | P0 | Product policy not implemented | [[Testing Expansion Backlog]] | | DISPUTE-001 | Buyer opens dispute before release | P0 | Backend incomplete / needs route alignment | [[Testing Expansion Backlog]] | | DISPUTE-002 | Admin resolves dispute for seller and release path is unblocked | P0 | Not complete | [[Testing Expansion Backlog]] | | DISPUTE-003 | Admin resolves dispute for buyer and refund path is unblocked | P0 | Not complete | [[Testing Expansion Backlog]] | | CI-001 | Code push builds and deploys backend/frontend/scanner via Woodpecker | P0 | Live used | [[Smoke and Regression Procedure]] | | UI-CHAIN-001 | Checkout shows BSC Testnet, tUSDT contract, and testnet explorer links | P1 | Implemented in frontend `2.8.118` | [[Scanner BSC Testnet Payment Procedure]] | | NOTIF-E2E-001 | Every E2E state-changing step issues expected notifications | P0 | Designed, needs automation | [[Notification Assertion Procedure]] | | PERF-CONC-001 | Ramp simultaneous full escrow E2E workers: 1, 2, 4, 8, 16, 32+ | P0 | Designed, needs automation and baseline report | [[Concurrency and Performance Profile]] | | AUTH-001 | Admin-created generated users can log in and execute role actions | P0 | Live used | [[Escrow Marketplace E2E Procedure]] | | CLEANUP-001 | Test users/requests can be identified and excluded from reports | P2 | Designed | [[Test Environment and Data]] | ## Core Escrow Scenario ```mermaid flowchart LR A["Create buyer and sellers"] --> B["Buyer creates purchase request"] B --> C["Sellers submit bids"] C --> D["Buyer accepts one bid"] D --> E["Buyer pays tUSDT on BSC Testnet"] E --> F["Scanner confirms payment"] F --> G["Seller delivers"] G --> H["Buyer confirms delivery"] H --> I["Assert notifications after every step"] I --> J["Policy boundary: grace, release, or dispute"] ``` ## Concurrency Scenario Family The concurrency profile runs the same full escrow worker in parallel and doubles the worker count until a stop condition is reached: ```text 1 -> 2 -> 4 -> 8 -> 16 -> 32 -> 64 ... ``` Each worker executes one isolated buyer/seller/payment/delivery flow with unique test users, request ids, destination addresses, and payment ids. Notification assertions remain mandatory inside each worker. See [[Concurrency and Performance Profile]]. ## Payment Negative Scenario Families | Family | What to mutate | Expected result | |---|---|---| | Wrong token | Pay old BSC Testnet USDT or USDC instead of canonical tUSDT | Scanner does not mark intended payment paid. | | Wrong chain | Pay on chain `56` or another EVM chain | Scanner watch for chain `97` remains pending. | | Wrong amount | Send less than expected base-unit amount | Direct-balance delta below threshold, no paid transition. | | Wrong destination | Send correct token/amount to another address | Intended destination delta unchanged, no paid transition. | | Duplicate payment | Send twice to same destination after paid | First payment confirms; second must not double-credit escrow ledger. | | Late payment | Pay after expiration/cancellation | Payment should not auto-credit an inactive intent without explicit recovery. | ## Release Policy Scenario Families These are not implemented yet, but they define the test shape we need before shipping fund release automation. | Product type | Expected policy | |---|---| | Physical product | Delivery proof starts a grace period. Funds release only after buyer confirmation, no dispute, or grace expiry. | | Gift card | Delivery should require immediate proof and release funds immediately or near-immediately after buyer acceptance, depending on final policy. | | Digital file/license | Same as gift card unless manual review is required. | | Service | May need milestone acceptance and dispute window. | ## Scenario Completion Criteria A scenario is complete when all are true: 1. It has a written procedure. 2. It has deterministic test data setup. 3. It captures expected API statuses and DB/business states. 4. It has at least one automated test or smoke script where practical. 5. It has a documented live-dev verification result. 6. It names residual risk or product gaps.