Mapping the application first

Testers who skip mapping find the weaknesses that are easy to find. The ones that matter are usually somewhere the interface never takes you.

Build four lists

Routes. Every endpoint, including those not linked from the interface: the client bundle, the API schema, documentation, mobile clients, old API versions nobody retired, and anything reachable in a staging copy.

Roles. Every kind of actor — anonymous, user, administrator, support, service, machine — and what each is supposed to reach. Get accounts for at least two of each kind; one account per role makes access control testing almost impossible.

Inputs. Parameters, headers, cookies, file uploads, webhooks, and anything the application reads from a third party. For each, where does it end up: a query, a template, a file path, a URL the server fetches, a message to another service?

Trust boundaries. Where does data cross from one level of trust to another? Browser to server, server to database, service to service, and anywhere a third party's content is rendered or acted upon.

Read the client

Modern front ends are a map of the server. The bundle contains route definitions, feature flags, role names and often endpoints that the interface hides from your account but the server still serves.

Understand the domain

Ask what the application is for, and write down its rules in plain sentences: "a refund cannot exceed the amount paid", "only the account owner can invite members", "a trial allows three projects". Each sentence is a test, and these are the tests that find the findings nobody else does.

Decide where the time goes

Finish mapping by writing down, explicitly, where the risk is concentrated — usually multi-tenant data access, money movement, and anything handling files or URLs. A day of mapping that redirects four days of testing is the best-spent day of the engagement.