nick/nick-doc
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: add testing procedures and scenario catalog

Browse Source
This commit is contained in:
Siavash Sameni
2026-06-06 10:35:47 +04:00
parent b3eea176d5
commit 9267961909
8 changed files with 1009 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
11 - Testing/Test Scenario Catalog.md Normal file
View File

@@ -0,0 +1,91 @@
---
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]] |
| 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["Policy boundary: grace, release, or dispute"]
```
## 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.