Skip to main content

Peak Mobile QA Checklist

Prerequisites​

  • Local QA smoke passes.
  • Peak Mobile Android/iOS hosts point at local management-api and merchant-api proxies.
  • Local Firebase emulator or approved local Firebase config is selected, with tenant ID, auth domain, and App Check/debug-provider mode recorded.
  • SDK transport profile records the management-api and merchant-api proxy base URLs, auth audience, local Gateway/payment-link stub base where used, and seeded org/store/user IDs.
  • Seed Peak tenant and mobile user permissions exist.
  • Simulator/device skip taxonomy is explicit: host-unavailable, emulator-unavailable, simulator-unavailable, device-unavailable, credential-gated, backend-unavailable, or provider-delivery.

Manual Local Checks​

  • Sign in and session restore.
  • Tenant/customer selection.
  • Verify local Firebase config, tenant token propagation, wrong-tenant denial, and revoked/expired session recovery.
  • Customer phone/loyalty/email/ID lookup through local management-api account POS overlays, including empty result, duplicate result, and API failure evidence.
  • Invoice create, issue, send, payment link generation, payment status update, idempotent duplicate-submit handling, and Gateway stub failure evidence.
  • Inventory lookup and adjustment through local management-api account POS overlays, including invalid adjustment, low-stock fixture, permission denial, and API failure evidence.
  • Notification registration path records local capture data for FCM/APNs token, invalid/missing token handling, and duplicate registration behavior.
  • Payment handoff through Gateway stub success/failure modes.
  • Offline/error states and retry.
  • Permission denial for limited user.

Source Surface Coverage Inventory​

Every item below must have automated host coverage, simulator/emulator evidence, manual evidence, or an open finding explaining why it cannot yet be proved locally.

  • auth: Android and iOS auth controller/session launch, sign-in, sign-out, session restore, expired token, revoked user, wrong tenant, and permission denial.
  • local backend mode: Firebase local config, SDK transport profile, management-api and merchant-api proxy base URLs, Gateway stub base, seeded tenant/org/store/user IDs, and request correlation are recorded before PASS.
  • customer: lookup by phone/email/customer ID, empty result, duplicate result, create/update where implemented, loyalty attach, and API failure.
  • feature resolution: feature-enabled, feature-disabled, stale feature cache, limited-user denial, and local permission seed proof.
  • foreground notification and notification registration: foreground receipt, background handoff where locally possible, invalid payload, missing token, duplicate registration, and capture evidence.
  • inventory: item lookup, adjustment, low-stock item, invalid adjustment, permission denial, empty result, and API failure.
  • invoice and remote invoice: create, issue, send, payment-link generation, remote invoice refresh, payment status update, cancellation/failure, retry, and idempotent duplicate-submit handling.
  • account invoicing: account invoice lookup, invoice detail refresh, payment-link generation, payment status polling, wrong-account or wrong-tenant denial, Gateway/provider failure preservation, and backend request-ID correlation on Android and iOS.
  • loyalty: lookup, enrollment/update where implemented, invalid customer identity, duplicate phone, earn/redeem where supported, and permission denial.

Primary Backend Workflow Proof​

Anchor ID: flow:peak-mobile-workflows

Local automated proof:

  • bazel test //apps/mobile:peak_mobile_lane_test
  • bazel test //apps/mobile:peak_mobile_android_api_clients_test
  • bazel test //apps/mobile:peak_mobile_workflow_parity_test
  • bazel test //apps/mobile:mobile_local_backend_workflow_evidence_test
  • bazel test //apps/mobile:peak_mobile_local_qa_contracts_test
  • bazel test //libs/sdks/kotlin/peak-pos-sdk:sdk_mobile_inventory_workflow_test
  • bazel test //libs/sdks/kotlin/peak-pos-sdk:sdk_mobile_invoice_workflow_test
  • bazel test //libs/sdks/kotlin/peak-pos-sdk:sdk_mobile_selling_workflow_test
  • bazel test //libs/sdks/kotlin/peak-pos-sdk:sdk_mobile_session_workflow_test
  • bazel test //libs/sdks/kotlin/peak-pos-sdk:sdk_mobile_workflow_smoke_test

Local manual audit:

  • Prerequisites: run the focused proof bundle after any Peak Mobile Android/iOS backend client, local-backend base URL, shared SDK mobile workflow, feature resolution, payment-link, or evidence-template change.
  • Steps: confirm Android and iOS backend client tests both preserve the same local session across customer lookup, inventory adjustment, invoice send, and payment-link generation; confirm each route records a distinct backend or Gateway-stub request ID; confirm the lane validator guards those proof names and request-ID markers; and confirm SDK mobile workflow tests still separate shared SDK contract drift from app-lane route/client regressions.
  • Expected evidence: passing Bazel commands, Android local base http://10.0.2.2:8085/api/v1/peak, iOS local base http://127.0.0.1:8085/api/v1/peak, request IDs req-customer-local-001, req-inventory-local-002, req-invoice-send-local-003, Gateway-stub ID gw-payment-link-local-004, and payment-link URLs using the local Gateway stub base.
  • Pass/fail criteria: pass only when both host lanes prove the primary backend workflow sequence with tenant/auth/App Check headers, idempotency keys, local-backend route correlation, and distinct request IDs, while SDK mobile workflow tests pass independently.

Staging manual audit:

  • Prerequisites: signed Peak Mobile Android/iOS build, staging Firebase config, staging tenant/org/store/user, staging management-api and merchant-api base URLs, and approved Gateway/payment-link staging path.
  • Steps: repeat the customer lookup, inventory adjustment, invoice send, and payment-link workflow from the installed app, then attach backend request IDs, Gateway correlation IDs, artifact checksum, and screenshots to the staging evidence packet.
  • Expected evidence: installed artifact checksum, staging request IDs, redacted tenant/user/store IDs, Gateway payment-link correlation, app screenshots, and explicit skip taxonomy for any unavailable provider/device dependency.
  • Pass/fail criteria: pass only when staging evidence is tied to the same signed artifact and every primary workflow route has backend or provider correlation evidence.

Offline, Denied, Retry, And Stale-State Proof​

Anchor ID: flow:peak-mobile-workflows

Local automated proof:

  • bazel test //apps/mobile:peak_mobile_lane_test
  • bazel test //apps/mobile:peak_mobile_android_api_clients_test
  • bazel test //apps/mobile:peak_mobile_local_qa_contracts_test
  • bazel test //apps/mobile:mobile_local_backend_workflow_evidence_test

Local manual audit:

  • Prerequisites: keep Android and iOS backend client matrix rows aligned for denied auth, stale session, offline invoice, offline inventory, payment-provider retry, and duplicate offline retry.
  • Steps: confirm each row records the workflow route, operator-visible recovery state, screenshot or log evidence, request ID/idempotency key or no-transport proof, backend mutation/no-mutation effect, duplicate side-effect protection, and allowed skip taxonomy.
  • Expected evidence: transport_blocked=request_count=0, duplicate_backend_side_effect=false, duplicate_rejected=true, offline_queue=draft_local_001>draft_local_002, local Gateway/request IDs, and simulator/device skip reasons from the checklist taxonomy.
  • Pass/fail criteria: pass only when denied and stale states prove no backend mutation, retryable offline states prove one mutation across replay, and all skipped device/provider paths name a concrete local limitation.

Staging manual audit:

  • Prerequisites: signed Android/iOS Peak Mobile artifact, staging tenant/user, staging Firebase/App Check configuration, local or staging Gateway payment stub/provider route, and request-log access.
  • Steps: repeat denied auth, stale session recovery, offline invoice sync, offline inventory sync, payment-provider retry, and duplicate retry from the installed app; attach screenshots/logs plus backend and Gateway correlation.
  • Expected evidence: artifact checksum, route/deep-link, org/store/user IDs, backend request IDs, Gateway request ID where applicable, idempotency key, before/after backend state, duplicate side-effect counts, and explicit skip taxonomy for unavailable device/provider paths.
  • Pass/fail criteria: pass only when every state has operator-visible evidence and the backend evidence shows no duplicate mutation across retry or stale-state recovery.

Release Artifact Evidence Manifest​

Anchor ID: flow:peak-mobile-workflows

Local automated proof:

  • bazel test //apps/mobile:mobile_release_artifact_evidence_test
  • bazel test //apps/mobile:mobile_release_artifact_manifest_test
  • bazel test //apps/mobile:mobile_store_screenshot_manifest_test
  • bazel test //apps/mobile:mobile_store_metadata_test
  • bazel test //apps/mobile:mobile_secrets_signing_evidence_test
  • bazel test //apps/mobile:mobile_android_release_lane_helpers_test
  • bazel test //apps/mobile:mobile_ios_release_lane_helpers_test

Local manual audit:

  • Prerequisites: release evidence rows remain PENDING until secret-backed CI and store-console proof exists.
  • Steps: use mobile-release-evidence.md#peak-mobile-release-artifact-evidence-manifest as the detailed audit source for artifact manifests, screenshot manifests, store metadata, signing cleanup, and credential classification.
  • Expected evidence: local validators prove the release evidence packet is complete and redaction-safe without claiming real Firebase/TestFlight/Play or App Store processing.
  • Pass/fail criteria: pass only when local proof and release/staging proof are separated and every release artifact/screenshot claim has manifest-row, checksum, app identity, and credential-classification evidence.

Manual Staging Checks​

  • Verify Firebase distribution/TestFlight builds.
  • Verify FCM/APNs delivery and DeviceCheck/Play Integrity.
  • Verify real payment handoff only with approved staging credentials.

Expected Evidence​

  • Local backend IDs for customer/invoice/payment link.
  • Local Firebase config identifier, tenant ID, SDK transport profile, management-api and merchant-api proxy base URLs, local Gateway stub base, and .dev-logs/qa/reports path.
  • Backend request IDs plus org/store/user, customer, invoice, payment-link, inventory adjustment, notification registration, and payment handoff IDs used for each PASS row.
  • Mobile screenshots.
  • Device/platform skip notes using the simulator/device skip taxonomy.