Mobile tests, and running the whole suite in CI

The final phase completes the picture: plan the mobile testing for AgentPay's agent app, and wire your whole suite into CI so it runs on every change — turning a set of tests into a living safeguard. This closes the capstone, and with it the course. This lesson walks the mobile-and-CI phase, and then steps back to what you have built.

Plan the mobile testing

AgentPay's field agents use a mobile app, so mobile is part of the product's risk — but, as the mobile-automation module argued, you automate it deliberately and thinly. Plan it rather than trying to reproduce everything on a phone:

• Manual mobile testing first — on real devices (the mobile-testing module): the money flow on a mid-range Android, low-connectivity and offline behaviour, permissions and interrupts, install and upgrade. These are high-value and much of it stays manual/exploratory.
• Automate only the critical mobile journeys with Appium — log in, record a transaction, see it confirmed — the money path on the phone. Keep this layer the thinnest of all (the mobile-reality lesson).
• Push logic to the API tests — the validation, permissions and idempotency are already covered fast and reliably at the API; the mobile suite only needs to prove the app uses that API correctly for the key journeys. Do not re-test rules through the flaky mobile UI.
• Use a device farm for real-device coverage across the fragmentation your users have, driven by analytics.

Write this as a short mobile test plan: what you test manually on devices, the few journeys you automate with Appium, and what you deliberately leave to the API layer. That plan is the deliverable — a realistic mobile strategy, not a sprawling Appium suite. (This course cannot run Appium for you, so this phase is planned and reasoned rather than executed — which is itself the honest lesson about mobile's cost.)

Wire the suite into CI

Now make your tests run automatically on every change (the ci-and-trust module). AgentPay ships a GitHub Actions workflow you can model yours on — it typechecks, runs the API tests, installs the browser, and runs the E2E tests on every push and pull request, uploading the Playwright report on failure:

- run: npm ci
- run: npm run typecheck
- run: npm run test:api                                   # the API suite
- run: npx --workspace=@agentpay/web playwright install --with-deps chromium
- run: npm run test:e2e                                   # the E2E suite (starts its own servers)
- uses: actions/upload-artifact@v4
  if: ${{ !cancelled() }}
  with: { name: playwright-report, path: apps/web/playwright-report/ }

Confirm it works: push a branch, watch the checks run, and — importantly — break something on purpose (make a test fail) and see the build go red and the report upload, so you know a real failure would be caught and diagnosable. Then make the checks required so a red build blocks the merge. Now your suite is not advisory; it guards main on every change.

Write the risk summary

Finish as a professional QA finishes an engagement: a short risk summary (the risk-based lesson). Honestly state:

• What you tested — the API rules/auth/permissions/idempotency (automated), the critical web journeys (automated), the manual exploratory sessions, the mobile plan.
• What you did not — what is lightly covered or out of scope (e.g. mobile automation not executed here, performance/load not tested, certain edge cases).
• The risk that remains — an honest read: "the money and access-control paths are well covered at the API and exercised in the UI; mobile is planned but not automated; performance is untested." No "everything is fine" — a real, useful picture for whoever decides to ship.

This summary is one of the most valuable things a QA produces, and writing it well is the mark of someone who understands that testing informs a decision rather than guarantees perfection.

What you have built — and learned

Step back and look at what the capstone produced for AgentPay: a test plan, designed test cases, an exploratory session and real bug reports; a fast, reliable automated API suite covering the rules, auth, permissions, idempotency and schema; a thin, trustworthy Playwright suite for the critical web journeys; a realistic mobile plan; the whole thing running in CI on every change; and an honest risk summary. That is the complete job of a QA — and it is exactly what a RizTech engagement would ask of you.

More than the artefacts, you have the judgement that made them good: designing before automating, testing at the right layer, guarding the money flow, waiting for conditions so the suite stays trusted, and reporting risk honestly. Tools will change; that judgement is what lasts. You started this course learning what a bug costs and what a QA is for — to protect the people who use the software — and you finish it able to do that work end to end, on a real system. That is what the course set out to teach, and what makes a trained RizTech intern ready for the real thing.

Check your work

Mobile plan (deliberate, thin): manual mobile testing on real devices first (money flow, connectivity/ offline, permissions, install/upgrade — much stays manual); automate only the critical mobile journeys with Appium (thinnest layer); push logic to the API tests (don't re-test rules on the flaky mobile UI); use a device farm for fragmentation. The plan is the deliverable (this course can't run Appium — planned, not executed).

CI: model AgentPay's workflow — npm ci, typecheck, API tests, install browser, E2E tests, upload report on failure; on every push/PR. Verify it: break a test on purpose, see red + report; make checks required so red blocks merge. The suite now guards main.

Risk summary: what you tested (API rules/auth/permissions/idempotency, web journeys, exploratory, mobile plan), what you did not (mobile automation, performance, some edges), and the honest remaining risk — never "all fine". Informs the ship decision.

What you built: plan + cases + exploratory + bug reports; a fast reliable API suite; a thin trustworthy Playwright suite; a realistic mobile plan; CI on every change; an honest risk summary — the complete QA job, plus the judgement (design before automate, right layer, guard the money, wait for conditions, report risk honestly) that made it good.

Practice

1. Write a mobile test plan for AgentPay: what you test manually on devices, the few journeys to automate, what stays at the API.
2. Explain why the mobile automation layer should be the thinnest, referring to cost and flakiness.
3. Write (or adapt) a CI workflow that runs your API and E2E suites on every push and PR.
4. Break a test on purpose in CI and confirm the build goes red and the report uploads; describe diagnosing it.
5. Make the CI checks required and explain how that protects main.
6. Write the final risk summary for AgentPay: tested, not tested, remaining risk — honestly.

Official documentation

• AgentPay reference repository — The full reference: API + web, tests, and CI workflow.
• Playwright — Continuous Integration — Running the suite in CI.
• Appium — Introduction — For planning the mobile automation.

Congratulations — you have completed the QA & Test Automation course. Go and test something real.