The brief: QA the AgentPay app

This is where everything comes together. Over eleven modules you learned to test manually, to test web and mobile and APIs, to automate across all three layers, to run it in CI, and to work as a QA. Now you do the whole job on one real application, from a cold start to a trusted automated suite. Your system under test is AgentPay — the reference app this course has referred to throughout — and this capstone is the brief for QAing it end to end. This lesson sets up the mission; the following four walk each phase.

Meet AgentPay

AgentPay is a mobile-money agent platform (the kind of system the course was shaped around). Field agents take deposits, withdrawals and payments for customers; an operations team watches transactions through a web console. It is a small but realistic system with exactly the surfaces a QA meets on the job:

An API (Fastify) — auth, agents, transactions with filtering/sorting/pagination, idempotent payments, role-based access, a dashboard summary.
A web console (React) — login, a transactions table with filters/sort/pagination, a new-transaction form, summary cards.
(And conceptually, an agent mobile app — the mobile testing you would do on a phone client.)

The code is public — the repository is linked on this course's page (RizTech-Academy/agentpay). Clone it, run it (npm install, npm run dev:api and npm run dev:web), and sign in with the seeded accounts in its README. You are now the QA for this product.

Your mission

Do the complete QA job on AgentPay, in the phases a real engagement follows:

Manual testing (next lesson) — understand the app, write a test plan, run an exploratory session, and file real bug reports. Test design before any automation.
API automation — automate the API test cases you designed: status, body, schema, auth, permissions, idempotency.
Web automation — automate the critical journeys through the browser with Playwright, reliably.
Mobile and CI — plan the mobile testing, and wire the whole suite into CI so it runs on every change.

By the end you will have done what a QA is hired to do: understood a product, tested it thoughtfully by hand, built a trustworthy automated suite at the right layers, and made it run continuously — the entire arc of this course, applied.

How to approach it

A few principles to carry through every phase, drawn from the whole course:

Think before you test. Understand what AgentPay is for and where the risk is (the money flow) before writing a single case. Risk-based testing decides where to spend your effort (the risk lesson).
Design, then automate. Do the manual test design first; automation without good test design just runs weak checks fast (the api-testing and automation-strategy lessons). Your manual cases become your automated tests.
Test at the right layer. Push rules and validation to fast API tests; reserve UI tests for real journeys; keep the mobile layer thinnest (the test-at-the-right-layer lesson).
Guard the trust. Wait for conditions not clocks, make tests independent with controlled data, and keep the suite reliable — a suite nobody trusts is worse than none (the flaky-tests and maintaining-trust lessons).
Focus on the money. AgentPay handles money; the transaction flow is the highest-stakes, highest-risk area, and it deserves the deepest testing everywhere — manual, API and UI (the money-flows lesson).

What "done" looks like

A strong capstone produces, for AgentPay:

A short test plan and a record of an exploratory session, with well-written bug reports for anything you find.
An automated API suite covering the rules, auth, permissions and idempotency, with schema validation.
A reliable Playwright suite for the critical web journeys (login, view/filter transactions, create a transaction, roles).
The suite running in CI on every change, with reports on failure.
A short risk summary: what you tested, what you did not, and the risk that remains.

You do not have to match the reference repo's tests — in fact, try to design yours before looking at theirs, then compare. The reference suite (21 API + 12 E2E tests) is there to check your thinking against, not to copy. Let us begin with manual testing.

Check your work

AgentPay is a mobile-money agent platform: an API (auth, agents, transactions with filter/sort/paginate, idempotent payments, roles, dashboard), a React web console, and conceptually a mobile agent app. Public repo (RizTech-Academy/agentpay) — clone, run, sign in with seeded accounts. You are its QA.

Mission (four phases): manual testing (plan, exploratory, bug reports), API automation (status/body/ schema/auth/permissions/idempotency), web automation (critical journeys in Playwright, reliably), mobile + CI (plan mobile; wire the suite into CI).

Approach: think before testing (risk — the money flow); design then automate (manual cases become tests); test at the right layer (rules→API, journeys→UI, mobile thinnest); guard trust (wait for conditions, independent data, reliable suite); focus on the money flow (highest risk, deepest testing).

Done looks like: a test plan + exploratory record + bug reports; an API suite (rules/auth/permissions/ idempotency/schema); a reliable Playwright suite for critical journeys; CI running it on every change; and an honest risk summary. Design yours before comparing to the reference (21 API + 12 E2E).

Practice

Clone and run AgentPay; sign in as admin and as an operator, and explore both the API and the web console.
In two sentences, state what AgentPay is for and where its highest risk lies.
List the four phases of the capstone and what each produces.
Identify AgentPay's surfaces (API, web, mobile) and which testing techniques from the course apply to each.
Write down, before testing, the three areas you expect to be riskiest and why.
Set up your working environment (repo cloned, servers running, a place for your test plan and notes).

Official documentation

AgentPay reference repository — The system under test: run it, read the README, sign in.
Ministry of Testing — Testing a new application — How to approach QAing an app you are new to.
Playwright — Getting started — The tool for the web-automation phase.

Next: a test plan, an exploratory session, and bug reports.