Our Banking Client: engineering blueprint

Payment APIs offer the first controlled test surface. Other applications follow their own readiness.

Current baseline: few shared environments and no backend virtualization. WireMock and per-run isolation are proposed pilot capabilities.

Adapters and joined evidence are integration work to build. Model output cannot change the original assertion result.

POST /transfers
Idempotency-Key: pay-142
{
  "from": "payer", "to": "recipient",
  "currency": "CAD",
  "amountMinor": 10000
}

same key + same payload → transfer t-142
same key + changed payload → conflict

journalCount(t-142) == 1
entryCount(t-142)   == 2
payer.balance      == 90000
recipient.balance  == 10000

Concurrent retries and repeated callbacks must converge on the same identity. Define key scope, retention and recovery with the service owner.

Authored contract; minor units are CAD cents. Start at 100000 / 0; no fees, FX or other account activity.

1. Runner → payment APIPOST /transfers · key pay-142 · amountMinor 10000
2. Payment API → providerSubmit transfer · provider accepts once
3. Payment API → journalCommit one journal · transfer t-142
4. Payment API ⇢ runnerResponse lost / timeout · outcome is unknown
5. Runner → payment APIRetry same key + same payload
6. Payment API → journalLookup original transfer · no second posting
7. Payment API → runnerReturn t-142 · assert one journal + balances

QE testing scenario. A timeout leaves the outcome unknown; a stable key must resolve to the original transfer.

requirement: PAY-142@r3
contract: payments-api@v1.4
fixture: cad-transfer@v2
amount_minor: 10000
key: pay-142
open_question: key-retention-window

same key + same payload -> original ID
same key + changed amount -> conflict
parallel retries -> one transfer
duplicate callback -> one posting
client timeout -> outcome still unknown
expired key -> rule needs domain approval

Proposed artifacts for the client scenario; identifiers and conflict behavior require agreement with the API owner.

{
  "run": "run-042",
  "currency": "CAD",
  "payer_minor": 100000,
  "recipient_minor": 0,
  "transfer_minor": 10000,
  "idempotency_key": "pay-142"
}

service_image: sha256:<digest>
test_commit: <commit-sha>
fixture_version: cad-transfer@v2
schema_version: payments@v8
provider_stub: accept-once@v3
account_scope: isolated-per-run
preflight: health + schema + balances
fault: drop API response after commit

Proposed manifest schema. Digest and commit placeholders must resolve to real immutable versions before execution.

retry = post_transfer("pay-142", 10000)
assert retry.status == 200

# This can pass after a duplicate debit.
# It cannot establish ledger correctness.

assert retry.id == original_transfer_id
assert journals(retry.id).count == 1
assert entries(retry.id).count == 2
assert sum_signed_entries(retry.id) == 0
assert balance(payer) == 90000
assert balance(recipient) == 10000

Non-runnable pseudocode for this CAD 100 test scenario; a REST Assured/JUnit implementation needs approved API and ledger helpers.

Test distribution follows behavior and observability. A new browser framework does not solve a shared settlement environment.

- task: PublishTestResults@2
  condition: always()
  inputs:
    testResultsFormat: JUnit
    testResultsFiles: 'results/TEST-*.xml'
    failTaskOnFailedTests: true
    failTaskOnMissingResultsFile: true
    failTaskOnFailureToPublishResults: true

inputs: [junit, run_manifest, logs]
access: read-only
output: diagnosis.json
evidence_links: required
change_test_status: prohibited
missing_artifact: unknown
merge_or_release: human-owned

Microsoft task syntax is documented; the AI adapter is proposed integration work. Job cancellation can still prevent artifact collection.

{
  "test": "PAY-142.retry",
  "observed": "journals=2; expected=1",
  "evidence": "run-042/ledger.json",
  "hypothesis": "replay posted twice",
  "classification": "needs-review",
  "owner": "payments-engineering"
}

preflight failed -> environment owner
assertion + ledger agree -> product review
unstable reproduction -> flake investigation
missing logs -> unresolved
approved fix -> new build + full rerun
original failing run -> retained

Proposed diagnostic schema and routing policy. Human review assigns the disposition; the original evidence remains available.

requirement: PAY-142@r3
test_commit: <commit-sha>
build_digest: sha256:<digest>
fixture: cad-transfer@v2
run: run-042
raw_results: results/TEST-payments.xml
disposition: defects/PAY-281
release_decision: pending-human-review

missing artifact -> UNKNOWN / block
required test skipped -> INCOMPLETE / block
ledger invariant failed -> FAILED / block
unresolved critical defect -> block
all required checks pass -> review eligible
release owner records final decision

Proposed evidence contract and pilot gate. This example does not supply a complete banking release policy.

Author the expected behavior independently. The browser demo covers a subset; these cases require service-level implementation.

Assess per application. Unknown or failed checks block the dependent execution scope; reviewed drafting has a narrower prerequisite set.

Each handoff carries a reproducible artifact and a named next owner.

Pilot team: one QA lead, four domain testers, two automation engineers and one data/environment engineer. Product, development and platform support contribute separately.

{
  "run": "run-042",
  "test": "PAY-142.retry",
  "trace_id": "trace-042",
  "transfer_id": "t-142",
  "idempotency_key": "pay-142",
  "raw_result": "failed"
}

JUnit: journals expected 1, observed 2
  -> trace-042: two post attempts
  -> t-142: two committed journals
  -> run-042: build + fixture + stub refs

AI hypothesis: replay posted twice
QA disposition: pending owner review

Proposed observability contract. Example identifiers are illustrative; the AI hypothesis does not override the failed assertion.

Do not promote a generated test merely because it compiles or passes once. Benchmark pilot effort separately.

1. Where is idempotency enforced: API, provider request, journal transaction and callback handler?
2. Which artifact proves one posting when the response is lost or the callback is duplicated?
3. Can two engineers reproduce the same failure from a pinned manifest and fresh fixtures?
4. Who owns provider-model drift, failed cleanup and evidence retention?

Resolve the contract, repeatability, ownership and evidence questions with system owners before expanding execution authority.

Foundation work starts with the pilot. Existing DevOps and QE maturity determine which capability can progress.

Control the payment provider for repeatable tests; keep a separate real-integration gate.

WireMock is an HTTP example. Contract fidelity, callback behavior and batch access need explicit owners; passing a stub does not prove end-to-end correctness.

The CI runner checks the real payment service and database against reviewed provider models. Retain separate provider and settlement evidence.

Choose Testcontainers, Compose or an existing supported environment for the test scope. Mobile devices and legacy settlement retain their own integration requirements.

PAY-142 must catch an incorrect transfer, journal or balance. The guided example rejects the candidate and leaves the maintained suite unchanged.

{
  "run": "run-042",
  "mode": "assisted",
  "scope": "PAY-142-api",
  "raw_result": "failed",
  "review_minutes": "not-recorded",
  "model_cost": "not-recorded",
  "rerun_count": "not-recorded"
}

defect challenge: detected / injected
case completion: executed / required
flake rate: unstable / repeated tests
review load: human minutes per case
time to disposition: failure to owner decision
net effort: draft + review + rerun + operation

Authored measurement schema; no pilot timing, cost or effectiveness observations have been recorded.

Repeatable execution is a platform capability. Retain failure evidence and attempt cleanup on every path; real integration remains separate.

Reuse CI execution and artifact storage. Add owned context, model and evidence adapters around those systems.

Proposed adapter contracts. Use request IDs for safe retries and record attempts; platform owners define timeouts and retention.

75 offshore QA staff share constrained environments. Proposed isolation and virtualized dependencies support parallel service tests; real integration stays scheduled.

Proposed integration paths. The CI assistant is read-only; bounded agents need isolated tools, independent checks and human approval.

Baseline and observed after: Not recorded. Freeze scope and definitions before comparing.

A clean control must pass; the intended injected-fault assertion must fail. Coverage and complete evidence do not imply a release pass.

Baseline and observed after: Not recorded. Freeze scope and definitions before comparing.

A passing retry never erases failure. Stubs do not prove real integration. Agree the independence of the reuse trial before measuring.

AI drafts; reviewers approve; CI executes. Context, artifacts and evidence remain versioned.

Authored trace IDs. Fixed assertions: original transfer ID, one journal, payer 90000 and recipient 10000 minor units.

Compare equivalent payment packs. Retain real-provider checks and measure review, rework and platform overhead.