Comprehensive Test Scenarios

Guided test plan for feature validation, concurrency/race conditions, and logical flows with examples and expected results.

feature test flow:

  1. refund all module check balance
  2. topup on all gateways check balance
  3. booking of all modules check balance
  4. change booking from admin side where prevouse booking amount is more then new booking some amount refund in wallet
  5. business - ex amount adjustment
  6. duplicate refund
  7. bus admin refund ( approvals )
  8. refund booking amount > 3000 should go in pending status confirm from admin and check balance
  9. train admin side refund
  10. car admin side refund
  11. do a topup from credit card that will go on pending for some time then quickly go to admin and confirm it from change booking topup confirm feature exist

concurrent testing

  1. refund a booking of a same wallet_id from two devices at the same time
  2. do multiple topups of same wallet_id from different devices at the same time
  3. do multiple booking of same wallet_id from different devices
  4. so different wallet bookings from different wallet devices at the same time
  5. do refund booking at the same time from mobile app website and admin side at the same time
  6. create a booking at the same time do business to excecutive adjustment from admin and as a customer refund the same booking from app

Suggestion: This category is typically called Concurrency Testing or Race Condition Testing. Use parallel execution, per-wallet locking, and assert no duplicates and correct final balances.

logical testing flow (same wallet)

Assumptions aligning with your docs:

  • Transaction types: IN (credit), OUT (debit)
  • Entry types include: booking, refund, topup, admin_refund, b2e_adjust, change_booking
  • Duplicate protection: unique (payable_id, type, transaction_ref)
  • Refunds > 3000 go to pending and require admin approval
  • Only successful transactions affect available balance

1) Make a booking pnr:123 (OUT)

Given wallet_id=5001, currency=PKR, starting balance=10,000

{
  "payable_id": 5001,
  "type": "OUT",
  "amount": 1_200,
  "currency": "PKR",
  "transaction_ref": "PNR-123",
  "entry_type": "booking"
}

Expected: 200 OK, booking recorded; New balance = 8,800; Ledger: one OUT:1,200 booking

2) adjust b2e pnr:123 (reduce amount)

Reduce fare by 300 (credit back difference)

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 300,
  "currency": "PKR",
  "transaction_ref": "PNR-123-B2E-REDUCE",
  "entry_type": "b2e_adjust"
}

Expected: 200 OK; New balance = 9,100; Ledger: IN:300 b2e_adjust

3) adjust b2e pnr:123 (increase amount)

Increase fare by 200 (additional debit)

{
  "payable_id": 5001,
  "type": "OUT",
  "amount": 200,
  "currency": "PKR",
  "transaction_ref": "PNR-123-B2E-INCREASE",
  "entry_type": "b2e_adjust"
}

Expected: 200 OK; New balance = 8,900; Ledger: OUT:200 b2e_adjust

4) change booking (admin) to cheaper fare

Old booking 1,200 → new booking 900; refund difference 300

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 300,
  "currency": "PKR",
  "transaction_ref": "PNR-123-CHANGE-REFUND",
  "entry_type": "change_booking"
}

Expected: 200 OK; New balance = 9,200; Ledger: IN:300 change_booking

5) duplicate refund attempt (same type/ref)

Replay the same refund

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 300,
  "currency": "PKR",
  "transaction_ref": "PNR-123-CHANGE-REFUND",
  "entry_type": "change_booking"
}

Expected: 409 Conflict (duplicate); Balance remains 9,200

6) admin refund > 3000 requires approval (pending)

Initiate admin refund of 3,500

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 3_500,
  "currency": "PKR",
  "transaction_ref": "PNR-123-ADMIN-REFUND",
  "entry_type": "admin_refund"
}

Expected (initiate): 202 Accepted; Transaction status=pending; Balance still 9,200

Expected (approve): On admin approval → status=successful; New balance = 12,700

7) bus admin refund (approvals)

Module-specific refund path with approval gate

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 700,
  "currency": "PKR",
  "transaction_ref": "BUS-REF-987",
  "entry_type": "admin_refund"
}

Expected (initiate): pending if policy requires; Expected (approve): balance increases by 700

8) train admin side refund

Immediate success if amount ≤ threshold

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 1_000,
  "currency": "PKR",
  "transaction_ref": "TRAIN-REF-555",
  "entry_type": "admin_refund"
}

Expected: 200 OK; Balance += 1,000

9) car admin side refund

Behaves same as train unless custom policy

{
  "payable_id": 5001,
  "type": "IN",
  "amount": 800,
  "currency": "PKR",
  "transaction_ref": "CAR-REF-321",
  "entry_type": "admin_refund"
}

Expected: 200 OK; Balance += 800

10) topup on gateway (credit card) → pending → admin confirm

Start topup of 2,000 (pending), then confirm

// initiate
{
  "payable_id": 5001,
  "type": "IN",
  "amount": 2_000,
  "currency": "PKR",
  "transaction_ref": "TOPUP-CC-888",
  "entry_type": "topup"
}
// confirm (admin)
POST /admin/topups/TOPUP-CC-888/confirm

Expected (initiate): 202 Accepted, status=pending, balance unchanged

Expected (confirm): status=successful, Balance += 2,000

11) booking of all modules check balance

Perform OUT bookings for bus/train/car and verify final balance equals starting balance minus all successful debits.

12) Combination: booking → partial change → admin refund >3000

Start bal=20,000; booking 6,000; change refund 1,000; admin refund 3,500 (pending then approve)

Expected balances by step:
1) After booking: 14,000
2) After change refund: 15,000
3) After admin refund (pending): 15,000 (no change)
4) After approval: 18,500

13) Increase on change (insufficient)

Balance=500; change requires additional 800 (OUT)

Expected: 422 Unprocessable Entity (insufficient balance); no mutation

Local Testing Tips

  • Use unique transaction_ref per (wallet, type) to avoid duplicate rejections during new attempts.
  • For concurrency tests, fire parallel requests and assert a single success, others fail gracefully with duplicate/idempotency messages.
  • Verify ledger sums equal stored balance after each successful step; pending items must not affect balance.

Need more detailed cases per module (bus/train/car)? Let me know and I’ll expand with module-specific amounts and policies.