You cannot test everything. Even Netflix does not performance-test every single button and dropdown in their app. Scope definition is about focusing your limited time and resources on the things that matter most. Think of it like a security guard deciding which doors to watch -- you cover the main entrance and the vault first, not the broom closet.
A "critical flow" is a user journey that meets at least one of these criteria: it is used by a large percentage of users (high traffic), it directly generates revenue (business impact), or its failure would make headlines (reputation risk). Here is a prioritization framework I use:
| Priority | Criteria | Example (Banking App) | Example (E-Commerce) |
|---|---|---|---|
| P0 -- Must Test | Revenue-critical or used by 80%+ users | Login, View Balance, Fund Transfer | Search, Product Page, Checkout, Payment |
| P1 -- Should Test | Used by 30-80% of users or has known issues | Transaction History, Bill Payment, Profile | Add to Cart, Wishlist, Order History |
| P2 -- Nice to Have | Used by <30% or low business impact | Settings, Help/FAQ, Branch Locator | Reviews, Gift Cards, Return Request |
| P3 -- Skip | Admin-only, rarely used, or static content | Admin Dashboard, CMS Pages | Admin Panel, Blog, About Us |
Once you have identified the user flows, break them down into individual API calls. A single user flow like "Login and Check Balance" might involve 5-8 API calls under the hood: authentication, session creation, dashboard data fetch, account list, balance query, recent transactions. You need to test all of them, not just the page-level flow.
User Flow: Login → Dashboard → Check Balance
Step 1: POST /api/auth/login → Get auth token
Step 2: GET /api/user/profile → Load user profile
Step 3: GET /api/dashboard/summary → Dashboard widgets
Step 4: GET /api/accounts → List all accounts
Step 5: GET /api/accounts/{id}/balance → Account balance
Step 6: GET /api/transactions?limit=10 → Recent transactions
Step 7: GET /api/notifications/count → Unread notifications
Total API calls per user session: 7
At 3,000 concurrent users: 21,000 API calls just for this one flow
Now imagine 5 different flows running simultaneously...
That is why scoping matters -- each flow multiplies the load.Defining what is OUT of scope is just as important as defining what is in scope. This prevents scope creep and sets clear expectations with stakeholders.
Q: How do you decide which scenarios to include in a performance test?
A: I use a risk-based approach. First, I identify all user flows and rank them by two factors: traffic volume and business impact. A flow that handles 60% of all traffic (like product search on an e-commerce site) is an obvious must-test. A flow that handles only 2% of traffic but generates 80% of revenue (like checkout) is also a must-test. I typically end up with 5-8 critical flows that cover 80-90% of the traffic. I also check with the dev team for any known bottlenecks -- maybe they recently changed the database schema or added a new microservice. Those changes go into the test scope even if the flow is not high-traffic. Finally, I document what is explicitly excluded and why, so stakeholders do not come back later asking "did you test the export feature?"
=== Performance Test Scope ===
Application: Banking Portal v3.2
Date: 2024-11-15
IN SCOPE (P0 -- Must Test):
1. Login Flow (POST /auth/login → GET /dashboard)
- Expected: 40% of all sessions
2. Balance Inquiry (GET /accounts/{id}/balance)
- Expected: 30% of all sessions
3. Fund Transfer (POST /transfers)
- Expected: 15% of all sessions, highest revenue impact
4. Transaction History (GET /transactions?account={id})
- Expected: 25% of all sessions
- Known concern: slow query on large accounts (500k+ transactions)
IN SCOPE (P1 -- Should Test):
5. Bill Payment (POST /payments)
- Expected: 10% of sessions
6. Account Statement Download (GET /statements/{id}/pdf)
- Expected: 5% of sessions but CPU-intensive
OUT OF SCOPE:
- Admin dashboard (internal, <10 concurrent users)
- Branch locator (static data, cached at CDN)
- Profile settings (low traffic, simple CRUD)
- Mobile push notifications (async, tested separately)
- Static assets (served via CloudFront CDN)
Mocked Dependencies:
- SMS gateway (WireMock stub, 200ms fixed delay)
- Email service (WireMock stub, no-op)
- Credit bureau API (WireMock stub, 500ms fixed delay)Use the 80/20 rule: 20% of your endpoints handle 80% of the traffic. Find those endpoints from access logs (sort by request count), and you have your core test scope. In most apps, just 5-8 API endpoints account for the vast majority of server load.
Key Point: Focus on high-traffic and high-impact flows -- use a P0/P1/P2/P3 prioritization framework and explicitly document what is excluded from scope to prevent scope creep.