A test plan, exploratory session and bug reports

Before any automation, do what a QA always does first: understand the app, plan the testing, explore it by hand, and report what you find. This phase is pure manual testing — the skills from module 2 — applied to AgentPay. It is the foundation everything else builds on: the cases you design here become the automated tests in the next phases, and the bugs you find here are the real output of testing. This lesson walks the manual phase of the capstone.

Step 1: understand and plan

Start by understanding AgentPay well enough to test it: run it, click through it, read the README, try the API. Then write a short test plan — not a bureaucratic document, but a clear statement of what you will test and how. For AgentPay it might cover:

Scope — what you are testing: login, the transactions list (filter/sort/paginate), creating a transaction, roles/permissions, the dashboard summary; the API and the web console.
Risk priorities — where you will focus (the risk lesson): the transaction/money flow first (highest impact and complexity), then auth and permissions, then the list operations, then the dashboard.
Approach — a mix of scripted test cases for the known rules and exploratory sessions for discovery.
What you will not test, and why — so the remaining risk is explicit.

The plan makes your testing deliberate rather than random, and it is where risk-based thinking earns its place: you decide, up front, to spend most effort on the money flow.

Step 2: design test cases

For the important areas, design test cases using the module-2 techniques — this is the design work that will also drive your automation. Take the create-transaction flow, the highest-risk area:

Equivalence partitioning and boundary values on the amount: a valid amount, zero, negative, the maximum (100000), just over (100001), non-numeric, missing. On the phone: a valid 10-digit number, wrong length, letters, missing.
Positive and negative cases: valid transaction → created; each invalid field → rejected with a clear message.
The money-specific cases: does a double-submit create two transactions? does a retry with the same idempotency key create a duplicate? (the money-flows lesson) — the highest-stakes cases.
Permissions: can an operator create a transaction for another agent? can they read another agent's transaction by changing the id in the URL/API? (the access-control cases the UI hides).

Write these as a simple table (case, input, expected result). This table is gold: it is your manual script and the specification for your automated API and UI tests.

Step 3: an exploratory session

Scripted cases check what you thought of; exploratory testing finds what you did not (the exploratory lesson). Run a time-boxed session with a charter — a focused mission — for example: "Explore the transactions list with a variety of filters and page sizes to discover problems with data correctness and pagination." For 45 minutes, investigate freely: combine filters and sorts and pages, try large and empty results, edit URL parameters, refresh mid-flow, open two tabs, act as different roles. Take notes as you go — what you tried, what you expected, what happened, anything surprising.

Exploration is where the interesting findings come from — the interaction bugs, the edge cases, the "that's odd" moments that no script would have listed. Follow your curiosity and your suspicion, and let what you learn suggest the next thing to try.

Step 4: write bug reports

When you find a problem, write a bug report that gets fixed, not closed as "cannot reproduce" (the bug-reports lesson). For each issue:

A clear title — what and where ("Operator can read another agent's transaction via direct ID").
Steps to reproduce — numbered, exact, from a known state, so anyone can follow them.
Expected vs actual — what should happen, what does.
Evidence — a screenshot for a UI bug, the request/response for an API bug (use the browser dev tools or Postman).
Severity and priority — how bad, and how urgently (kept separate — the severity lesson). An access-control or money bug is high severity.

Keep the tone factual and blame-free (the working-with-developers lesson) — you are helping the team ship better software, not scoring points.

What good looks like for this phase

By the end of the manual phase you should have: a short test plan naming scope and risk priorities; a test-case table for the key flows (especially the money flow); notes from at least one exploratory session; and clear bug reports for anything you found. Do this honestly before touching automation — because the quality of your automated suite depends entirely on the quality of the test design you do here. Automation runs your thinking; make the thinking good first.

Check your work

Understand + plan: run and explore AgentPay, then write a short test plan — scope (login, list ops, create, roles, dashboard; API + web), risk priorities (money flow first, then auth/permissions, then list, then dashboard), approach (scripted + exploratory), and what you will not test. Deliberate, risk-based.

Design test cases with module-2 techniques on the high-risk create-transaction flow: equivalence/boundary on amount and phone, positive/negative per field, money-specific (double-submit, idempotent retry), and permissions (create/read for another agent — the id-swap). A case/input/expected table — your manual script and automation spec.

Exploratory session: a time-boxed, charter-driven session (e.g. filters/pagination and data correctness); investigate freely, take notes; find what scripts miss.

Bug reports: clear title, exact repro steps, expected vs actual, evidence (screenshot / request-response), severity + priority (separate; access-control and money bugs are high). Factual, blame-free.

Practice

Write a one-page test plan for AgentPay with scope, risk priorities and what you will not test.
Build a test-case table for the create-transaction flow using equivalence partitioning and boundary values.
Design the money-specific and permission test cases (double-submit, idempotent retry, id-swap access).
Run a 45-minute charter-driven exploratory session on the transactions list and record your notes.
Write two full bug reports for issues you find (or plausibly could), with repro steps and evidence.
Mark each of your test cases and bugs with severity and priority, and justify the money/access ones as high.

Official documentation

AgentPay reference repository — The app to test; run it and explore.
Ministry of Testing — Exploratory testing & charters — Running a charter-driven session.
Playwright — Trace viewer — Capturing evidence for bug reports (also useful manually).

Next: automating the API tests.