docs: add testing procedures and scenario catalog

11 - Testing/Testing Overview.md

@@ -0,0 +1,73 @@
+---
+title: Testing Overview
+tags: [testing, qa, e2e, smoke]
+created: 2026-06-06
+---
+
+# Testing Overview
+
+This section is the home for Amanat test procedures and designed test scenarios.
+It complements [[07 - Development/Testing]], which documents the test runners and
+repository-level commands.
+
+Use this section when planning or executing end-to-end validation across buyer,
+seller, payment scanner, delivery, payout, dispute, and deployment behavior.
+
+## Documents
+
+| Document | Purpose |
+|---|---|
+| [[Test Environment and Data]] | Environments, accounts, wallets, tokens, and secret-handling rules. |
+| [[Test Scenario Catalog]] | Canonical scenarios we have designed or need to extend. |
+| [[Escrow Marketplace E2E Procedure]] | Buyer/seller/request/bid/delivery procedure, including the current two-round flow. |
+| [[Scanner BSC Testnet Payment Procedure]] | BSC Testnet tUSDT scanner payment procedure and failure modes. |
+| [[Smoke and Regression Procedure]] | CLI, CI, and post-deploy smoke checks. |
+| [[Testing Expansion Backlog]] | Gaps to cover before broader release confidence. |
+
+## Test Layers
+
+| Layer | Goal | Primary owner |
+|---|---|---|
+| Unit tests | Validate isolated services, state machines, utilities, components. | Backend/frontend/scanner repos |
+| Integration tests | Validate repository adapters, payment orchestration, webhooks, auth, marketplace APIs. | Backend/frontend repos |
+| Smoke tests | Fast checks for one deployment target, usually via `BASE_URL`. | Backend scripts |
+| Browser E2E | Validate user-visible web flows. | Frontend Playwright |
+| Live dev E2E | Validate real dev deployment, CI image, scanner service, BSC Testnet, and test tokens. | QA/operator |
+| UAT | Validate product scenarios and acceptance criteria. | Product + QA |
+
+## Golden Path Coverage
+
+The minimum live-dev confidence path is:
+
+1. Admin creates one buyer and at least two sellers.
+2. Buyer creates a request with a bounded USDT budget.
+3. Each seller submits a bid inside the budget with different amount and delivery timing.
+4. Buyer accepts one bid.
+5. Buyer funds escrow with BSC Testnet tUSDT.
+6. Scanner confirms the token transfer.
+7. Seller delivers.
+8. Buyer confirms delivery.
+9. Flow pauses at the current product-policy boundary: release/grace/dispute automation is not complete.
+
+The current live tested version of this path is documented in
+[[Escrow Marketplace E2E Procedure#Reference execution - 2026-06-06]].
+
+## Definitions
+
+| Term | Meaning |
+|---|---|
+| Dev deployment | `https://dev.amn.gg`, backed by the dev Docker stack on the deployment host. |
+| Scanner | Separate in-house AMN scanner service that verifies token payments. |
+| Direct-balance rail | Scanner payment mode where balance deltas on a destination address confirm payment. |
+| BSC Testnet tUSDT | Test ERC-20 used for dev payments: `0x109F54Dab34426D5477986b0460aE5dFBA65f022`. |
+| Grace period | Product-policy delay after delivery before automatic fund release. Not implemented yet. |
+| Immediate release | Product-policy mode for digital goods such as gift cards. Not implemented yet. |
+
+## Rules
+
+- Never commit seed phrases, private keys, admin passwords, CI tokens, or `.env` files.
+- Use generated test users with unique run IDs. Do not reuse personal accounts for destructive scenarios.
+- Record enough evidence to reproduce a failure: request id, offer id, payment id, tx hash, chain id, token address, HTTP status, and CI build number.
+- Treat a passing local test as necessary but not sufficient for scanner/payment work. Payment changes must also be verified against dev after deploy.
+- Every live-dev test should state what remains untested or blocked.
+